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Bluetooth: vision, goals, and architecture 

Jaap Haartsen, Mahmoud Naghshlneh, Jon Inouye, Olaf J. Joeressen, Warren Allen 

October 1998 ACM SIGMOBILE Mobile Computing and Communications Review, Volume 

2 Issue 4 
Publisher: ACM 

Full text available: ^ pdf(953.51 KB) Additional Infornnation: full citation , abstract , references 

A few years ago it was recognized that the vision of a truly low-cost, low-power radio- 
based cable replacement was feasible. Such a ubiquitous link would provide the basis for 
portable devices to communicate together in an ad hoc fashion by creating personal area 
networks which have similar advantages to their office environment counterpart - the 
local area network (LAN). Bluetooth is an effort by a consortium of companies to design a 
royalty free technology specification enabling this ... 
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Yaniv Shaked, Avishai Wool 

June 2005 Proceedings of the 3rd international conference on Mobile systems, 

applications, and services MobiSys '05 
Publisher: ACM Press 



Full text available: pdf(223.67 KB) 



Additional Information: full citation , abstract , references , cited by . index 



terms 



This paper describes the implementation of an attack on the Bluetooth security 
mechanism. Specifically, we describe a passive attack, in which an attacker can find the 
PIN used during the pairing process. We then describe the cracking speed we can achieve 
through three optimizations methods. Our fastest optimization employs an algebraic 
representation of a central cryptographic primitive (SAFER+) used in Bluetooth. Our 
results show that a 4-digit PIN can be cracked in less than 0.3 sec on an old ... 

3 Mobile applications: Bluetooth and WAP push based location-aware nnobile 
^ advertising system 

^ Lauri Aalto, Nicklas Gothlin, JanI Korhonen, Timo Ojala 

June 2004 Proceedings of the 2nd international conference on Mobile systems, 
applications, and services MobiSys '04 

Publisher: ACM Press 

^ „ . ^ I.. « -ir/..^r^ oo ^^^^^ Additional Information: full citation , abstract , references , citings , inde x 
Full text available: ^ pdf(469.83 KB) 

Advertising on mobile devices has large potential due to the very personal and intimate 
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nature of the devices and high targeting possibilities. We introduce a novel B-I^AD system 
for delivering pernnlssion-based location-aware nnobile advertisennents to mobile phones 
using Bluetooth positioning and Wireless Application Protocol (WAP) Push. We present a 
thorough quantitative evaluation of the system in a laboratory environment and 
qualitative user evaluation in form of a field trial in the real envir ... 

Keywords: Bluetooth positioning, context-aware, location-aware, location-based 
services, mobile advertising, wireless advertising 



4 Quality-of-service in IP sei^ices over Bluetooth ad-hoc networks 
Wah-Chun Chan, Jiann-Liang Chen, Po-Tsang Lin, Ka-Chin Yen 
December 2003 Mobile Networks and Applications, Volume 8 issue 6 
Publisher: Kluwer Academic Publishers 

Full text available: ^ pdf(469.36 KB) Additional Information: full citation , abstract , references , index terms 

Along with the developnnent of nnultimedia and wireless networking technologies, mobile 
nnultimedia applications are playing more important roles in information access. Quality of 
Service (QoS) is a critical issue in providing guaranteed service in a low bandwidth 
wireless environment. To provide Bluetooth-IP services with differentiated quality 
requirements, a QoS-centric cascading mechanism is proposed in this paper. This 
innovative mechanism, composed of intra-piconet resource alio ... 

Keywords: BNEP protocol, Bluetooth-IP access system, handoff, quality of service, 
resource allocation 



5 Performance of Bluetooth bridges in scatternets with limited service scheduling | 
Vojislav B. Misic', Jelena Misic' 

February 2004 Mobile Networks and Applications, Volume 9 issue i 
Publisher: Kluwer Academic Publishers 

.- .. . ^ .... 0k ^r/cco Additional Information: full citation , abstract , references , index ternns , 

Full text available: fn pdf(552.34 KB) 

review 

The performance of two Bluetooth piconets linked through a bridge device is analyzed 
using the tools of queueing theory. We analyze both possible cases, i.e., when the bridge 
device is the nnaster in one of the piconets and a slave in the other (MS bridge), as well as 
when the bridge device is the slave in both of the piconets (SS bridge). Analytical results 
are derived for the probability distribution of access delay (i.e., the time that a packet has 
to wait before being serviced) and end-to-end ... 

Keywords: Bluetooth, Bluetooth scatternet, master/slave bridge, performance 
evaluation, queueing theory, slave/slave bridge 



6 Bluetooth dynamic scheduling and interference mitigation 
N. Golmie 

February 2004 Mobile Networks and Applications, volume 9 issue i 
Publisher: Kluwer Academic Publishers 

.- .. . ^ ■. 0 -.r,-,r^^ ixox Additional Information: full citation , abstract, references , index terms . 

Full text available: TO pdf(1 94.60 KB) — : 

1^=*"^ review 

Bluetooth is a cable replacement technology for Wireless Personal Area Networks. It is 
designed to support a wide variety of applications such as voice, streamed audio and 
video, web browsing, printing, and file sharing, each imposing a number of quality of 
service constraints Including packet loss, latency, delay variation, and throughput. In 
addition to QOS support, another challenge for Bluetooth stems from having to share the 
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2.4 GHz ISM band with other wireless devices such as IEEE 802.11. ... 
Keywords: Bluetooth, MAC scheduling, WPANs, interference 



7 Platforms: Bluetooth and sensor networks: a reality check 
Martin Leopold, Mads Bondo Dydensborg, Philippe Bonnet 

November 2003 Proceedings of the 1st international conference on Embedded 

networiced sensor systems SenSys '03 
Publisher: ACM Press 

Full text available: fglDdf(356.11 KB) '^formation: full citation , abstract, references , citings, index 

terms 

The current generation of sensor nodes rely on commodity components. The choice of the 
radio is particularly important as it impacts not only energy consumption but also 
software design (e.g., network self-assembly, multihop routing and in-network 
processing). Bluetooth Is one of the most popular commodity radios for wireless devices. 
As a representative of the frequency hopping spread spectrum radios. It is a natural 
alternative to broadcast radios in the context of sensor networks. The questio ... 

Keywords: bluetooth, mac layer, network self-assembly, sensor nodes 



8 Rendezvous layer protocols for Bluetooth-enabled smart devices | 
Frank Siegemund, Michael Rohs 

July 2003 Personal and Ubiquitous Computing, volume 7 issue 2 
Publisher: Springer-Veriag 

Full text available: ^ pdf(445.27 KB) Additional Information: full citation , abstract , index terms 

AbstractCommunication platforms for ubiquitous computing need to be flexible, self- 
organizing, highly scalable and energy efficient, because in the envisioned scenarios a 
large number of autonomous entities communicate in potentially unpredictable ways. 
Short-range wireless technologies form the basis of such communication platforms. In this 
paper we investigate device discovery in Bluetooth, a candidate wireless technology for 
ubiquitous computing. Detecting new devices accounts for a significa ... 

Keywords: Adaptive rendezvous protocols, Bluetooth, Context, Cooperative device 
discovery. Energy efficiency, Inquiry parameters, Rendezvous layer 



9 Emerging technologies: WLANs and WPANs: On the application of traffic engineering J 
^ over bluetooth ad hoc networks 

^ Sachin Abhyankar, Rishi Toshiwal, Carlos Cordeiro, Dharma Agrawal 

September 2003 Proceedings of the 6th ACM international workshop on Modeling 

analysis and simulation of wireless and mobile systems MSWIM '03 
Publisher: ACM Press 

Full text available: ^ pdf(420.12 KB) Additional Information: full citation , abstract , references , index terms 

The seamless communication of data and voice over short-range, point-to-multipoint 
wireless links between mobile and/or stationary devices is becoming a reality by newly 
introduced Bluetooth radio technology for Wireless Personal Area Networking, which can 
support only up to 1 Mbps of nominal bandwidth. It is based on a master-slave model 
where double the resources are allocated for any slave-to-slave communication via the 
master. In addition, it does not have any mechanism to serve demands exce ... 

Keywords: bluetooth, performance evaluation, piconet partitioning, role switching, traffic 
engineering 



http://portal.acm.org/results.cfm?query=bluetooth&querydisp=bluetooth&start= 1 &srt=scor. . . 12/1 9/07 



Results (page 1): bluetooth 



Page 4 of? 



10 Bluetooth: a technical overview 

Myra Dideles 
^ June 2003 Crossroads, volume 9 issue 4 
Publisher: ACM Press 

Full text available: [S| htm(38.37 KB) Additional Information: fui! citation , references , index terms 



An ns-based Bluetooth Topology Construction Simulation Environment 
Chia-Jui Hsu, Yuh-Jzer Joung 

March 2003 Proceedings of the 36th annual symposium on Simulation ANSS '03 
Publisher: IEEE Computer Society 

Full text available: ^ pdf(470.02 KB) Additional Information: full citation , abstract , index terms 

Bluetooth is an emerging technology in wireless appllcations,and nnany related issues are 
yet to be explored bothin acadennia and industry. Because of the complexity andthe 
dynamics of computer networks, a good simulation toolplays an important role in the 
development stage. Of the existingsimulation tools, ns is a popular, open-source 
packagethat has a substantial support for simulation of TCP,routing, and multicast 
protocols over wired and wirelessnetworks. It also has BlueHoc as its extension f ... 

12 Interference evaluation of Bluetooth and IEEE 802.11b systems 
N. Golmie, R. E. Van Dyck, A. Soltanian, A. Tonnerre, O. Rebala 
May 2003 Wireless Networks, volume 9 issue 3 
Publisher: Kluwer Academic Publishers 

I- II * ^ I ui 0t ^r/ono ixD\ Additional Information: full citation , abstract , references , citings , index 

Full text available: Tn pdf(203.73 KB) ^ 

^-r^ terms 

The emergence of several radio technologies, such as Bluetooth and IEEE 802.11, 
operating in the 2.4 GHz unlicensed ISM frequency band, may lead to signal interference 
and result in significant performance degradation when devices are colocated in the same 
environment. The main goal of this paper is to evaluate the effect of mutual interference 
on the performance of Bluetooth and IEEE 802.11b systems. We develop a simulation 
framework for modeling interference based on detailed MAC and PHY model ... 

Keywords: Bluetooth, IEEE 802.11b, WPANs, interference 



13 Bluetooth: A pseudo random coordinated scheduling algorithm for Bluetooth 
scatternets 

Andras Racz, Gyorgy Miklos, Ferenc Kubinszky, Andres Vaiko 

October 2001 Proceedings of the 2nd ACM international symposium on Mobile ad hoc 
networking & computing MobiHoc '01 

Publisher: ACM Press 

I- II * ^ I 01 ^f/o-to A-r i^D\ Additional Information: full citation , abstract , references , citings , index 

Full text available: Tg pdf(218.47 KB) 

^ terms 

The emergence of Bluetooth as a default radio interface allows handheld devices to be 
rapidly interconnected into ad hoc networks. Bluetooth allows large numbers of piconets 
to form a scatternet using designated nodes that participate in multiple piconets. A unit 
that participates in multiple piconets can serve as a bridge and forwards traffic between 
neighbouring piconets. Since a Bluetooth unit can transmit or receive in only one piconet 
at a time, a bridging unit has to share its time among t ... 

Keywords: Bluetooth, inter-piconet communication, scatternet, scheduling 
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14 Multimedia support over bluetooth Piconets 

Rohit Kapoor, Manthos Kazantzidis, Mario Geria, Per Johansson 
^ July 2001 Proceedings of the first worlcshop on Wireless mobile internet WMI '01 

Publisher: ACM Press 

Full text available- t^ pdf(808.15 KB) Additional Information: full citation , abstract , references , citings, index 
' l^d-^ terms 

In this paper we explore the ability to support nnultimedia traffic in indoor, wireless ad hoc 
PANS (Personal Area Networks) using the Bluetooth technology. We first define the 
representative ad hoc networl<ing applications such as wireless access to the Internet, 
document distribution, videoconferencing, webcasting, interaction with sensors and 
actuators, etc. For such applications, we define the performance requirements placed on 
the PAN. There are two technologies now competing for the ... 

Keywords: Piconets, WaveLAN, bluetooth, multimedia, video, voice 



15 Interference of bluetooth and IEEE 802.11: simulation modeling and performance | 
evaluation 

N. Golmie, R. E. Van Dyck, A. Soltanian 

July 2001 Proceedings of the 4th ACM international workshop on Modeling, analysis 
and simulation of wireless and mobile systems MSWIM '01 

Publisher: ACI\/I Press 

f- ^ M u. 01 -.^/crr-To-i lXD^ Additional Information: fuii citation , abstract , references , citing s, index 

Full text available: TO pdf(657.91 KB) ^ 

^^^^^-^^ terms 

The emergence of several radio technologies such as Bluetooth, and IEEE 802.11 
operating in the 2.4 GHz unlicensed ISM frequency band may lead to signal interference 
and result in significant performance degradation when devices are co-located in the same 
environment. The main goal of this paper is to present a simulation environment for 
modeling interference based on detailed MAC and PHY models. This framework is then 
used to evaluate the impact of interference on the performance of Bluetoot ... 

Keywords: IEEE 802.11, WPANs, bluetooth, interference 



16 Emerging threats: A preliminary investigation of vtform infections in a bluetooth 
^ environment 

^ Jing Su, Kelvin K. W. Chan, Andrew G. Miklas, Kenneth Po, AM Akhavan, Stefan Saroiu, Eyal 
de Lara, Ashvin Goel 

November 2006 Proceedings of the 4th ACM workshop on Recurring malcode WORM 
'06 

Publisher: ACM Press 

Full text available: ^ pdf(876.85 KB) Additional Information: fuii citation , abstract , references , index terms 

Over the past year, there have been several reports of malicious code exploiting 
vulnerabilities in the Bluetooth protocol. While the research community has started to 
investigate a diverse set of Bluetooth security issues, little is known about the feasibility 
and the propagation dynamics of a worm in a Bluetooth environment. This paper is an 
initial attempt to remedy this situation. We start by showing that the Bluetooth protocol 
design and implementation is large and complex. We gather traces ... 

Keywords: Bluetooth, malware, worms 
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17 Performance monitoring: Performance evaluation of web services invocation over 
^ Bluetooth 

^ Vincenzo Auletta, Carlo Blundo, Emiliano De Cristofaro, Guerriero Raimato 

October 2006 Proceedings of the ACM international workshop on Performance 

monitoring, measurement, and evaluation of heterogeneous wireless 
and wired networks PM2HW2N '06 

Publisher: ACM Press 

Full text available: ^ pdf(506.38 KB) Additional Information: full citation , abstract , references , index terms 

Mobile devices should allow users to exploit services anytime, without any place 
restriction and in a transparent way. The Bluetooth technology achieves this feature, by 
providing services at a low cost and with a low power consunnption. In a few years, most 
of the devices accessing the web services will be mobile. In this paper, we evaluate 
performance of a framework allowing a Java application programmer to directly interface 
Web Services from a mobile device using a Bluetooth connection. Our w ... 

18 Quality of service: Evaluation of the energetic impact of Bluetooth low-power modes 
for ubiquitous computing applications 

Juan-Carlos Cano, Jose-Manuel Cano, Eva Gonzalez, Carlos Calafate, Pietro Manzoni 
October 2006 Proceedings of the 3rd ACM international wori<shop on Performance 
evaluation of wireless ad hoc, sensor and ubiquitous networks PE- 
WASUN '06 
Publisher: ACM Press 

Full text available:^ pdf(756.49 KB) Additional Information: full citation , abstract , references , index ternns 

In order to further increase the applicability of Bluetooth in real applications, reducing the 
energy consunnption and hardware cost are important research topics. In this paper we 
present a wireless connmunication prototype to support ubiquitous computing, which has 
been implemented based on commercial Bluetooth off-the-shelf components. It allows 
every object to be augmented with processing and communication capabilities in order to 
make them "smart". We investigate on the power characteristics ... 

Keywords: Bluetooth, Bluetooth measurements, power consumption, ubiquitous 
computing 

19 Service support: SymPhone: design and implementation of a VoIP peer for Symbian 
^ mobile phones using Bluetooth and SIP 

^ Patrick Stuedi, Andreas Frei, Luc Burdet, Gustavo Alonso 

September 2006 Proceedings of the 4th international worl<shop on Wireless mobile 

applications and services on WLAN hots pots WMASH '06 
Publisher: ACM Press 

Full text available: ^ pdf(454.17 KB) Additional Information: fuii citation , abstract , references , index terms 

VoIP is born fronn the growing Internet infrastructure, which has over the years seen 
significant improvements in both bandwidth and end-to-end latency. In this paper, we 
explore making VoIP available on a mobile phone. For that purpose, we propose an 
architecture and describe the various components involved. Data entering and leaving the 
mobile phone is encapsulated in a wireless Bluetooth connection. The bridge to the 
Internet is provided by a linux Bluetooth access point. The system is compati ... 

Keywords: SIP, VoIP, bluetooth, symbian 
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Additional Information: full citation , abstract , references , citings , index 
terms 

One factor that has linnlted the use of Bluetooth as a networking technology for publicly 
accessible nnobile services is the way in which it handles Device Discovery. Establishing a 
Bluetooth connection between two devices that have not seen each other before is slow 
and, from a usability perspective, often awkward. In this paper we present the 
implennentation of an end-to-end Bluetooth-based mobile service framework designed 
specifically to address this issue. Rather than using the standard Blueto ... 
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Abstract — Recently, Bluetooth has been regarded as a 
promising solution to an inexpensive wireless connection. 
Although initial application of Bluetooth technology has 
been focused mainly on replacing cables between hand-held 
devices, general wireless telecommunication such as public 
Internet access via a Bluetooth-equipped device is. expected 
to be one of the most popular applications in the near fu- 
ture. However, it is not well understood whether perfor- 
mance of Bluetooth- based systems Is sufficient for such an 
application. In this paper, we present preliminary results of 
performance evaluation of a Bluetooth-based Internet access 
point. The evaluation is based on simulation of an Internet 
access model consisting of a Bluetooth- based network ac- 
cess point and a number of Bluetooth-equipped notebook 
computers. The simulation results indicate that Bluetooth 
provides performance comparable to the fastest dial-up mo- 
dem even when a number of users share a single Bluetooth 
radio unit. Better performance is expected when more than 
one Bluetooth radio unit are employed such that each unit 
services different users concurrently. However, Bluetooth 
units in a single radio range (about 10m) interferes each 
other since the channels established by each unit occasion- 
ally collide at the same frequency band. This paper analyzes 
the impact of such interference based on an analytical model 
of inter-channel interference. The analysis shows that the 
performance improves as the number of channels increases 
up to 40. We expect the proposed inter-channel interference 
model is useful in the design of systems facilitating multiple 
Bluetooth units. 



I. Introduction 

Interconnection of consumer devices lias been increas- 
ingly important as the use of hand-held devices sucli as 
PDA's and celluar phones becomes increasingly popular. 
Iii the past, these devices were usually connected via a se- 
rial cable that requires physical wiring between two devices 
before they can excliange information. To avoid sucli incon- 
venience, a wireless communication technology has highly 
been demanded by users. Bluetooth is one of such technolo- 
gies and especially attractive in the environment of hand- 
held devices since a low cost is an important requirement 
of such a technology [1]. Due to its low cost, Bluetooth 
is expected to be embedded in many consumer devices in 
the near future. Combined with the demand for access to 
the Internet everywhere in public places, a Bluetooth-based 
public Internet access point is expected to be popular. 

WJjile protocol models for Bluetooth- based access net- 

Tliis research was supported in part by the Ministry of Education 
under the BK21 program. The first author was supported from the 
Basic Research Program (for the woman scientists) of the Korea Sci- 
ence &i Engineering Foundation. 



works have been proposed in the literature [2] [3], their per- 
formance is yet to be known. In this paper, we present a 
simulation model of Internet access based on the Bluetooth 
technology. The model consists of an Internet access point 
and a number of user devices each equipped with a Blue- 
tooth radio. To evaluate' the perfonnance of the model, 
we have developed a sinmlator that accurately models the 
behavior of each user's requests to Internet access and ac- 
tions occurred in the Internet access point to service the 
requests. Since the radio in the Internet access point is 
shared by multiple users, a suitable scheduling policy is 
necessary to select which user will be serviced next. A plain 
round- robin policy seems to be a good choice since it is sim- 
ple to implement yet provides fairness. We also consider 
two other scheduling policies called a weighted jvund-ivbiri 
and a multi-level round-robin. Tlie simulation results show 
that both policies improve the performance by up to 35% 
over the plain round-robin pohcy. 

Performance can further be improved by facilitating mul- 
tiple Bluetooth radios in the Internet access point. It would 
be ideal if the performance boosts up to N times when N 
Bluetooth radios are used. However, since more than one 
radio may use the same carrier band due to the nature of 
Frequency Hopping Spread Spectrum (FHSS) [4], the effec- 
tive performance is less than N times especially when N 
becomes larger. This paper analyzes the performance of a 
Bluetooth system with multiple radios using a probabilistic 
model reflecting the interference. 

This paper is organized as follows. The following sec- 
tion describes the Internet access model and the simula- 
tion methodology. Section III presents the simulation re- 
sults along with detailed analysis. Section IV analyzes the 
impact of multiple Bluetooth radio units in the Internet 
access point. Finally; Section V gives concluding remarks. 

II. Evaluation Model and Methodology 

A Bluetooth-based Internet access point is a system that 
provides Bluetooth-equipped devices with access to the In- 
ternet. It consists of a Bluetooth radio unit through which 
data communications occur with user devices, and an in- 
terface to the wire-based network infrastructure leading to 
the Internet, The main role of the Internet access point is 
to establisli a wireless connection to each user device and 
forward user's packets to/ from the wired network. 

A Bluetooth-based Internet access point may liave either 
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a single or multiple radio units. Also, the radio units may 
act as a master or a slave. This gives us a design space 
encompassing four possible combinations: (1) single slave 
unit, (2) single master unit, (3) multiple slave units, (4) 
multiple master units. In the first combination, the Inter- 
net access point acts as a slave while each user device acts 
as a master establishing it's own piconet to coiniect to the 
Internet access point. In this setup, the total bandwidth 
of the radio link is shared by all of the user devices. How- 
ever, this design requires the slave unit to switch from one 
piconet to another, which takes up to one frame. This over- 
head is significant when switching occurs frequently, e.g., 
in the order of a few frames. 

The second design choice is the Internet access point with 
a single radio unit that acts as a master of a piconet with 
all user devices as slaves. Wlien the radio is in the master 
mode, it controls all the slaves participating in the piconet 
by determining which slave exchanges data with the mas- 
ter. This design is more efficient than the first design since 
the overhead of piconet switching is not present. 

Tlie remaining two designs are extensions of the two ini- 
tial designs with additional radio units in the Internet ac- 
cess point. This allows load-sharing between radio units 
and hence improves both the total bandwidth and the max- 
imum number of users, at the costs of additional radio 
units. However, multiple radio units may interfere each 
other by occasionally colliding at the same frequency band, 
whose performance impact is anajyzed in Section IV. 

In the simulation, we assume the second design. We 
also assume that the number of slaves is limited to seven 
in order to remove the effect of parking that is required 
when more than seven slaves are to be connected to a mas- 
ter. We focus on the throughput and delay per user in a 
steady-state environment where no users Join or depart the 
piconet. For the evaluation, we have developed an event- 
driven, packet-level simulator using PARSEC developed^ 
UCLA as a successor to Maisie [5]. 

As for the Internet access model, we use a closed queuing 
simulation model that processes Internet web surfing traffic 
as shown in Figure I. In this model, a user with a notebook 
generates traffic by clicking on the screen after consuming 
a UserThinkTime. The user's request is inserted into a up- 
load queue in which the transmission is delayed until the 
master's polling is received. This delay is called a BluetooUi 
upload scheduling delay and dependent on the scheduling 
policy of the master. After the upload ifcheduling delay, 
the notebook that is polled by the master sends the user's 
request to the Internet Access Point (AP) and the AP for- 
wards the request to the Internet. IiiieiyietAcceasTivit is 
the time for the AP to receive the user-requested data from 
the Internet since the request is submitted. When the re- 
quested data is ready, the data is inserted into the down- 
load queue and stays there until the corresponding note- 
book is polled. This delay is called a BluetooUi doumload 
scheduling delay and also affected by the sclieduling policy 
of the master. At this time, AP performs segmentation if 
necessary based on the length of the message. 

The packets used in the experiments include NULL and 




Fig. 1. Bluetooth simulation model 



TABLE I 
Parameter values for experiment 



Parameter 


Average Values 


Message Length 


[5 Kbytes, 50 Kbytes, 250 KBytes 
500 Kbytes, 1000 Kbytes] 


IntemetAccessTime 


[0.5s, Isj 


UserThinkTime 


[0.1s, Is, 2a, 3s, 48, 5s] 



POLL packets for control data transmission, and DHl, 
DH3, and DH5 packets for user data transmission. We 
assume fixed-length upload data and variable-length down- 
load data reflecting the asymmetric nature of the Internet 
traffic. The parameter values used in the simulation are 
shown in Table I. The IntemetAccessTime and the t/ser- 
ThinkTime are random variables distributed exponentially 
with averages shown in the table. The message length is 
also a random variable, distributed uniformly. Each siam- 
lation is performed for a window of 24 hours. 

We measure the performance by throughput and delay. 
The throughput is defined as the rate of data transmitted to 
a slave in a time unit. As for the delay, two nxeasurements 
are considered: completiori delay and user delay. The user 
delay is defined as the time between the user^s click and 
the arrival of the first packet of the requested data. It 
is equal to the sum of Bluetooth upload sdxeduling delay, 
Intej-netAccessTiine, and download scheduling delay. The 
completion delay is defined as the time between the user's 
click and the arrival of the last packet of the requested 
data. The completion delay represents the time until the 
requested service is completed. 

As mentioned before, the Bluetooth upload and down- 
load scheduling delays are affected by the scheduling poHcy 
of the master. In Bluetooth specification 1.0, a round-robin 
(RR) is implicitly assumed as the underlying scheduling 
policy. Li an RR policy, a master polls its slaves one by 
one in a fixed order. A slave is allowed to transmit a mes- 
sage in a designated slot only when it has been addressed 
by the master in the preceding slot- Thus the polling se- 
quence of the master is critical to the Bluetooth scheduling 
delay. The RR policy is fair in the sense that each user re- 
ceives the same number of polls. Although it seems fair, a 
slave with download data should wait for other slaves even 
when the other slaves do not need to be serviced. 

In this paper, we consider two other scheduling poli- 
cies to improve the delay: weighted round robiii (weighted 
RR) and multi-level rvund robin (nmlti-level RR). In the 
weighted RR, the master polls a slave up to « times suc- 
cessively when there is data that needs to be transmitted 
to the slave, while slaves with no data is polled only once. 
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(a) Message length = 5 Kbytes (b) Various message length 
Fig. 2. Throughput per user 

This policy improves the completion delay as we will see 
in the next section. On the other hand^ the multi-level RR 
can improve the user delay, as well as the completion delay 
by grouping the slaves into two classes, one consisting of 
slaves with download data and the other consisting of slaves 
with no data. In this policy, tlie master polls all the slaves 
belonging to the first class up to n times successively, prior 
to polling the slaves belonging to the second class, which 
are poUed only once as in the case of the weighted RR. 

III. Perform A KCE Evaluation 

This section presents the simulation results based on the 
Internet access model described in the previous section. 
Figure 2- a shows the throughput per user for various num- 
bers of users and UserThinkTimes (denoted as UTT) in the 
Internet access model where the average message length is 
5 Kbytes ajid Inter-netAccessTime is 1 second in average. 
■ As we can see from the figure, the throughput is largely 
independent on the number of users when the piconet is 
not overloaded. Figure 2-b shows sinmlation results where 
the average message length is varied from 5 Kbytes to 1000 
Kbytes while UserThinkTimes is fixed to 2 seconds. In 
contrast to the previous results, when the average message 
length exceeds 250 Kbytes, throughput per user decreases 
by up to the ratio of 1 /n as the number of users increases to 
n. However, it still outperforms the fastest dial-up modem 
(56 Kbps) in the marketplace even when a single Internet 
access point is shared by seven users. 

Figure 3 shows the performance in terms of delay. Fig- 
ure 3-a shows the completion delay for various message 
lengths ranging from 5 Kbytes to 1000 Kbytes. The com- 
pletion delay increases up to 50 seconds as the number of 
users increases when the average message length is 1000 
Kbytes due to the heavy traffic. However, when the av- 
erage message length is below 5 Kbytes, the completion 
delay is less thaji 5 seconds regardless of the number of 
users. Figure ^b shows the measurement of user delay in 
the same environment. In contrast to the completion de- 
lay, variation of user delay is very small for the range of 
message lengths we consider. Moreover, most of the user 
delay is due to the IntemetAccessTime whicli is fixed to 1 
second in the simulation. The above results indicate that 
the Bluetooth-based Internet access service is feasible in 
terms of delay as well as throughput. 

In the previous experiments, it is assumed that the 



(a) Completion delay (b) User delay 

Fig. 3. The variation of delay for the message length 
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(a) Message length = 5 Kbytes (b) Message length = 50 Kbytes 
Fig. 4. Completion delay in weighted RR 

round-robin is the underlying scheduling policy. In the 
following, we present the simulation results for the other 
two policies relative to the round-robin assuming Interne- 
tAccessTime and Usei ThinkTime are 0.5 sec and 1 sec in 
average, respectively. Figure 4 shows the completion de- 
lay of weighted RR normalized to RR for various numbers 
of successive polls for eacli user, denoted as n. The results 
show that the weighted RR policy improves the completion 
delay by up to 15% when the traffic is low, as shown in Fig- 
ure 4-a. When the traffic is heavy, the improvement is even 
more evident as shown in Figure 4-b. where improvemeixt 
is by up to 20%. Similar results are observed for other val- 
ues of parameters, although they are not included in this 
paper. 

However, weighted RR increases the user delay although 
it improves the completion delay. Figure 5 shows the mea- 
surement of the user delay as well as the completion delay, 
both of which normalized as the completion delay of RR. 
When the load is low, increase in the user delay is marginal 
as shown in Figure 5-a. However, when the piconet is over- 
loaded, the user delay increases by up to 24% compared to 
RR as shown in Figure 5-b. Note that the increase of the 
user delay is relatively small compared to the reduction in 
the completion delay. Overall, weighted RR policy gives 
performance improvement of up to 20% compared to RR. 

The delay of weighted RR can be improved by giving 
priority to the users with download data as explained in 
Section II. Figure 6 shows the completion delay of the 
multi-level RR normalized to the delay of RR. The figure 
shows that weighted RR improves the completion delay 
by up to 25% when the load is high, and by up to 15% 
even when the load is low. From the results, we can notice 
that multi-level RR is even more efficient than weighted RR 
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(a) Message length = 5 Kbytes (b) Message length = 50 Kbytes 
Fig. 5. User delay in weighted RR 
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(a) Message length = 5 Kbytes (b) Message length = 50 Kbytes 

Fig. 6. Completion delay in multi- level RR 

especially in ai» overloaded situation. The results also sliow 
that the best performance is achieved when the parameter 
value of n is set properly based on tlie transaction unit. 

Figure 7 shows the results of the user delay along with 
the couipletioii delay. Similarly to weighted RR, when the 
load is low, difference in the user delay is marginal. "How- 
ever, when the load is high, the user delay increases by 
up to 15%. Note that this number is much smaller tlian 
the case of weighted RR. where the increase is by up to 
24%. The results show that the multi-level RR improves 
the completion delay better than weighted RR witli smaller 
increase in the user delay. Thus, in the Internet web surfing 
environment with burst traffic, scheduling policies based on 
a transaction unit such as the weiglited RR and the multi- 
level RR are better than policies based on a frame unit 
sucli as the pure round robin. 

IV. Analysis ok Inter- channel Interference 

In the previous sections, a single Bluetooth unit in the 
Internet access point is assumed to service several users by 
forming a piconet consisting of all the users and the Inter- 
net access point. In this setting, all piconet members share 
a single Bluetooth channel under the control of the mas- 
ter of the piconet. A Bluetooth channel follows a unique 
frequency hopping sequence determined by the Bluetooth 
address of the master. Since different Bluetooth chaimels 
use different frequeJicy hopping sequences, more than one 
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Fig. 7. User delay in niulti-Ievel RR ' 

Bluetooth diannel can co-exist in a single Bluetooth cell. 
This gives a design choice of facilitating multiple Bluetooth 
units in a single Internet access point. However, multiple 
cliaimels interfere with each other by occasionally using 
the same frequency band. Specifically, there are 79 differ- 
ent frequency bands defined in the Bluetooth specification 
[6] and the probability of two independent channels us- 
ing the same frequency band at any given time is 1/79. 
If both channels transmit a message simultaneously when 
this happens, a collision occurs and eventually the message 
is garbled. 

Of course, Bluetooth has a mechanism to detect if a 
message is garbled and retransmit it if so. On the receipt 
of a message, the recipient sends the acknowledgement to 
the sender, usually piggybacking on the next message. If 
the sender does not receive a proper acknowledgement, the 
message is retransmitted, usually at the next hop. Note 
that Bluetooth does not require a back-off meclxanism to 
avoid repetitive collisions on retransmission, in contrast to 
other MAC protocols such as ALOHA since tlie probability 
of collision at the next hop is independent of the collision. 
This also simplifies the probabilistic model of collisions as 
given in the following. 

We begin our analysis with the probability of a message 
transmitted in a cliannel being garbled by another chan- 
nel. For simplicity, we assume that eacli message occupies 
a single Bluetooth slot and all channels are aligned each 
other so that the start of each slot is synchronized. Un- 
der this assumption, the probability of a message being 
garbled by another channel is the product of two probabil- 
ities, the probability of two cliannels hopping onto the same 
frequency band and the probability of a message being car- 
ried in a slot. The latter can be thought of as a normalized 
load carried over a channel including both new messages 
and retransmitted messages. If we denote this term as G, 
the probability of a message being garbled is given as G/79. 
Tlien the probability of a message not being garbled when 
there are N channels with the same cliaracteristic, is equal 
to the probability of a message not garbled by any of TV - 1 
channels. Hence, we get 

P^ocom«on(N) = (l-G/79)'^-^ (1) 

In addition to the message, the corresponding acknowl- 
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Fig. 8. Throughput characteristic 

edgeinent also needs to be transmitted without being gar- 
bled in order that a message is regarded as transmitted 
successfully by the sender. If we ignore the case of possible 
forward error correction and assume that the probability 
of an acknowledgement being garbled is the same as a mes- 
sage being garbled, the probability of a transmission being 
successful is: 

P{N) = PnoconuioniN)' = (1 - G/79)^<'''-'^ (2) 

Given the probability of a transmission being successful 
P{N) and the carried load G, we obtain the ratio of mes- 
sages transmitted successfully on a channel, i.e.. through- 
put, by multiplying G by P(N). 



5 = GP(N) = (7(1 - G/79)-^^-^J 



(3) 



The aggregated throughput of all of iV cliajmels, i.e., the 
throughput of the Internet access point, is given simply as 
S nmltipVied by JV: 

S{N} = NGP{N) = NG(l - G/79)'^^^-'^ (4) 

The relationship between S and G for various N is shown 
in Figure 8. The figure shows that for smaller N the 
throughput S increases almost linearly as the carried load 
G increases. However, for large N, throughput does not 
increase beyond certain points, similarly to ALOHA [7]. 
For example, when N is 128, 5 increases towards the max- 
imuni value until G reaches about 0.3 and drops beyond 
this point. Such threshold can be obtained by differentiat- 
ing S by G, 



dS 



^G(l 



.G/79)2(^-») 



= {l-C7/79)2<^-i)-i(l-^G) 

By setting Equation 5 equal to zero, we get G ~ 79/ (27V - 
1). Since C? < 1 by definition, we get N > 40. This implies 
that such threshold exists only when N is greater than 40. 
Thus the threshold Gmax is represented as follows: 



_ / 1 



if iV < 40 
otherwise 



(6) 



Gmaz for ranges of .'V is plotted in Figure 9- a. Replacing G 
in Equation C with Gmax^ we obtain the maximum through- 
put Smax(^) as sJiown in Figure 9-b. The figure clearly 
shows that the maximum througliput does not improve 



(a) Carried load (b) Maxiinuixi throughput 

Fig. 9. Maximum throughput analysis 




Fig. 10. Alignment of channels 

when N increase beyond 40. FVom the results, we can 
conclude that the performance of the Internet access point 
improves as the number of Bluetooth units increases up 
to 40 although the improvement becomes smaller due to 
inter- channel interference. 

The previous analysis assumes that each message occu- 
pies a single slot and the cliannels are aligned with each 
other as shown in Figure 10-b (Case B). In this subsection, 
we try to relax the second assumption. When cliannels are 
not aligned as in the case shown in Figure 10-c (Case C), 
a message can collide by either of two messages in a chan- 
nel, increasing the probability of a collision. On the other 
hand, Figure 10-a shows the case where the acknowledge- 
ment cannot be garbled by the other cliannel, improving 
tlie probability of a transmission being successful. Assum- 
ing that the three cases are generated randomly and that 
all the messages are carried over DHl packets, the proba- 
bility of eacli case is given as follows: 




PI = 0.2128, 
If = 0,6160, 
1 = 0.1712 



(7) 



where pi, p3, and p3 represent the probability of two clian- 
nels being in Case A, Case B, and Case C, respectively, and 
/t, m, and / represent the length of the header of a DHl 
packet (126 /isec), the length of a DHl packet hicluding 
the header (366 /isec), and the length of a slot (625 /isec), 
respectively. 

Applying binomial twice, we obtain the normalized 
throughput S'{N) as follows: 



xpf-'-**^'^»iVG(l-(7/79)^- 
xp?^yVG(l-<?/79)2' 
x;4NG(l-C;/79)3i 
= /VG(1 - 0/79)'"^-* 

xpf''-*"^^>pj;^3(l-C/79)'+^j 



(8) 
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(a) aligned-channel mode] (b) unaligned-cbannel model 

Fig. 11. Comparison of both models (DHl) 




(a) DH3 (b) DH5 

Fig. 12. Throughput in on unaligned channels 

Figure 11 compares the previous model {aligned'channel 
modd) aiid the i-elaxed model {unaligned- channel model). 
The figure shows that tlie difference between two models is 
marginal. It is due to the fact that the Case A (probability: 
0.2128) and Case C (probability: 0.1712) offset each other 
and Case B (probability: 0.6160) dominates, whicli is the 
same case as the previous model. 

In the case of DH3 or DH5. the equation remains un- 
changed but the probability pi, pa, and p3 are computed 
in a sliglitly different manner: 
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where m'^"^ and jti^^^ are the size of a DH3 packet (1598 
/isec) and the size of a DH5 packet (2862 ^isec), respec- 
tively. The results are shown in Figure 12. Since ps 
is greater compared to the case of DHl, the normalized 
throughput is reduced due to a larger collision probabil- 
ity. Note that this does not imply that the performance 
is reduced by using DH3 / DH5 instead of DHl. since 
the throughput shown in the figure is normalized by the 
throughput of a single channel using DH3 and DH5. re- 
spectively. In fact, the use of DH3 / DH5 improves the 
performance since the overhead of packetization is much 
less than DHl. From the results, we can notice that both 
models show similar characteristics and reflect the rela- 
tionsliip between the number of chaimeis and the resulting 
aggregated throughput. 



V. Conclusion 

Today, access to the Internet is essential in e very-day life. 
It is hard to think of business, research, and entertainment 
without tlie Internet. Therefore, it is a requirement, rather 
than aji option, to facilitate functionality of Internet access 
in hand-held devices such as PDA for everywhei-e- Internet 
services. Since Iiand-held devices require low cost and low 
power consumption, Bluetooth has been regarded as one 
of the most promising solutions for a wireless connection 
between the user devices and the wired network infrastruc- 
ture. 

la this paper, we have presented preliminary results on 
the performance of a Bluetooth-based access network. In 
the performance evaluation, we have modeled a simple In- 
ternet access scenario and simulated while varying the val- 
ues of various parameters including user 's think times, mes- 
sage lengths, and Internet access delay. The simulation 
results indicate that the Bluetooth-based access network 
provides performance of tens of Kbps to hundreds of Kbps 
depending on the number of users. This result is encour- 
aging since the Bluetooth- based access network gives per- 
formance significantly better than the traditional dial-up 
network without the tedious wire connection. The perfor- 
mance can be improved if multiple Bluetooth radio units 
are used in the Internet access point. We have shown that 
the performance improves as the number of Bluetooth units 
increases up to 40 based on an analytical model. 

As a future work, we plan to develop a more general 
Bluetooth simulation package including a traffic generator 
that refiects a variety of traffic such as ftp, e-mail, and 
name-card exchange. We expect the simulation package 
will allow us to evaluate various aspects of Bluetooth sys- 
tems including issues on scheduling policies, segmentation 
and reassembly, parking of user devices that are largely ig- 
nored in this paper. We also expect thorough evaluation 
with the new simulation tool would reveal possible causes 
of performance bottlenecks in the Bluetooth system. 
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THE IMMINENT MARKET EXPLOSION OF BLUETOOTH 
WIRELESS INTERFACES ON PRODUCTS SIGNALS AN RF 
MEASUREMENT FIRST FOR MANY TEST ENGINEERS. 

On your marks for 
testing Bluetooth 



THE Bluetooth wireless standard is coming 
into its own, and hundreds of millions of Blue- 
tooth-enabled products will ship by the end of 
2002. The Bluetooth technology will be self-con- 
tained within many products; for others, it will be an 
addition in the form of a PC Card that plugs into a 
mobile device or a dongle that plugs into a desktop 
system's RS-232 or parallel-printer port. As Blue- 
tooth becomes ubiquitous, you 11 find yourself hav- 
ing to test Bluetooth devices at the protocol-stack 
and RF levels. 

A complete Bluetooth module comprises a radio 
transceiver, a baseband-link controller, and a link 
manager (Figure 1). The baseband-link controller 
connects the radio hardware to the baseband-pro- 
cessing and physical protocol layer. The link man- 
ager performs high-level protocol activities such as 
link setup, authentication, and configuration. Ap- 
plication-layer software sits above the link manager. 

A Bluetooth implementation can operate as a sin- 
gle-chip (integrating radio and protocol stack) or 
multi-chip (separate radio and protocol ICs) design. 
Cellular-phone manufacturers may wish to combine 
the Bluetooth baseband function in the same device 
as the GSM (Global Standard for Mobile Commu- 
nication) baseband function and, therefore, will 
want a separate Bluetooth radio. A digi- 
tal camera manufacturer is more likely to 



under test (Figure 2). For these tests, the test system 
must be able to support the Bluetooth protocol to 
make the link. Consequently, you can expect instru- 
ment vendors to develop new test instruments sim- 
ilar to the integrated radio test sets for digital cellu- 
lar radio. 

For protocol tests, you can use protocol sniffers 
that monitor and display data moving between Blue- 
tooth devices. You can also use products such as the 
EBDK (Ericsson Bluetooth Development Kit) (Ref- 
erence 1). Ericsson will soon release a version of the 
EBDK, known as a Blue Unit, that will include soft- 
ware for use during early qualification testing. Even- 
tually, some companies should develop complete 
reference test systems. 

A profile is the application level protocol that 
makes a device perform its functions as the user ex- 
pects. All Bluetooth devices that claim to offer a giv- 
en functionality must use the appropriate profile 
from the Bluetooth specification. This requirement 
ensures interoperability between common devices 
from multiple vendors. 

For example, the LAN access profile defines a data 
connection between a DT (data terminal) and a LAP 



Figure 1 



select a single-chip design to simplify^ assembly. 

RF, PROTOCOL. AND PROFILES 

Three aspects of a Bluetooth module need testing: 
RF, protocol, and profiles. You can perform many of 
the RF measurements with standard test instru- 
ments such as spectrum analyzers with vector de- 
modulation, transmitter analyzers, power meters, 
digital-signal generators, and BERTs (bit-error-rate 
testers). 

Some of the measurements, however, require the 
radio to form a standard Bluetooth radio-link con- 
nection with the test instrument and the test in- 
strument to have some control over the equipment 

Thxs article appeared in Test & Measurement World/ 
September 2000. 
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A complete Bluetooth module comprises a radio transceiver, 
a baseband-lmk controlla', and a link manager. 
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(LAN access point). The profile defines 
the following services and connection 
states for the application layer: initializa- 
tion of LAN access service, shutdown of 
LAN access service, establishment of LAN 
connection, loss of LAN connection, and 
disconnection of LAN connection. 

Until a reference test system is avail- 
able, early Bluetooth profile testing will 
require product-to-product interoper- 
ability testing. To facilitate this, a series of 
"Unplugfests" have been arranged by the 
Bluetooth Special Interest Group 
(www.bluetooth.com). At these meet- 
ings, companies with functional prod- 
ucts can test product interoperability 
against products from other suppliers. 

RF AND SINGLE-CHIP MEASUREMENTS 

The Bluetooth radio specification out- 
lines the performance requirements for 
the radio and the test to confirm confor- 
mance (Table 1). To measure the per- 
formance of a Bluetooth module, the test 
instrumentation must be able to estab- 
lish a Bluetooth link with the EUT 
(equipment under test). It can then put 
the EUT into test mode. Test mode is a 
mandatory feature of a Bluetooth mod- 
ule in which the EUT can enter a loop- 
back mode or can disable frequency hop- 
ping for making BER measurements, for 
example. A Bluetooth test system should 
also be able to disable hopping, set spe- 
cific frequencies for tests, and control the 
transmit power level. 

During design and development, you*ll 
want to test the radio in isolation from 
the protocol stack that controls it. In 
these cases, you need to control the ra- 
dio so you can set frequencies and levels 
to make raw transceiver measurements. 



Figure 2 
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You can then feed the 
radio output 
directly into a 
spectrum analyzer 
with vector signal 
analysis or into a 
transmitter analyzer 
and power meter to 
make the measure- 
ments (Figure 3). 
The measurements 
you can make will 
vary according to the 
control that the ra- 
dio IC manufacturer 
provides over the IC 
connectors. The radio will have inputs 
controlling data in and out, Tx on, clocks, 
and supply voltage. Without a protocol 
stack, the radio may not frmction at all. 

Many radio designs permit you to feed 
PRBS (pseudo-random bit sequences) 
into the transmitter modulator and use 
manufacturer-specific control lines to 
force the radio to transmit continuously 
at one frequency. Doing so enables you to 
make frequency, power, and modulation 
measurements as well as output spec- 
trum measurements. As an alternative 
method to radio IC testing, you can build 
a test jig that holds the radio IC and has 
a protocol stack built onto it. This 
method allows for comprehensive testing 
and simulates the integrated module ap- 
proach outlined below. 

There is no standard for the interface 
between a protocol stack and a radio, typ- 
ically kn9wn as the radio interface. You 
must use a test fixture to hold the radio IC 
and provide it with some baseband con- 
trol to give Bluetooth frinctionality This 
arrangement lets you test radio ICs with 
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Some Bluetooth tests require the test instrument to support the Blue- 
tooth protocol to form a standard Bluetooth radio-link connection. 



a Bluetooth link and baseband control. 

The connection between the radio and 
the test instrument vary depending upon 
the Bluetooth device implementation. 
Some radios or integrated modules have 
printed antennas as part of the design. In 
this case, you may only be able to make a 
connection over the air to an antenna on 
the test instrument input. If you use this 
approach, then you must characterize the 
path loss for each of the 79 Bluetooth fre- 
quencies. If the radio IC has an RF out- 
put connector, a direct connection to the 
test instrument simplifies calibrated 
power and sensitivity measurements. 
Even if you use a direct connection, 
though, you should measure and correct 
for the path loss at each frequency. 

TESTING OEM BLUETOOTH PRODUCTS 

OEMs buying commercial Bluetooth 
chip sets still need to test. Inevitably, 
packaging can influence the performance 
of a finished product because of the an- 
tenna s position as well as other internal 
electronics. In a mobile phone, the other 



HOW TO QUALIFY PRODUCTS WITH BLUETOOTH INTERFACES 



No product may be sold as 
"Bluetooth enabled" without first 
demonstrating compliance with 
the Bluetooth specification. You 
can refer to the rules laid out in 
the Bluetooth Qualification Pro- 
gram when you check compli- 
ance. Qualification is essential for 
ensuring that consumers have a 
good experience with Bluetooth- 
branded products. You must 
make sure that interoperability 
between products supplied by 



different manufacturers is guar- 
anteed. 

To obtain qualification, a man- 
ufacturer must first become a 
Bluetooth member by signing 
the adopters agreement. Two ad- 
ditional bodies help qualify a 
product: a BQTF (Bluetooth 
Qualification Test Facility) and a 
BQB (Bluetooth Qualification - 
Body). 

A BQTF is an acaedited or- 
ganization with the skills and 



equipment to test a product 
based on the Bluetooth specifi- 
cation. A BQTF may choose not 
to offer qualification for every as- 
pect of the Bluetooth standard. 
For example, many profiles are 
limited to a few specific applica- 
tions, and some aspects of the 
Bluetooth specification are op- 
tional. The BQTF performs meas- 
urements on behalf of the man- 
ufacturer on the appropriate 
radio, protocol, and profiles for 



the equipment under test. The 
BQTF prepares a test report that 
forms part of a compliance fold- 
er that is submitted to the BQB. 

The role of the BQB is to re- 
view all submitted documenta- 
tion and ensure that all the ap- 
propriate tests have been 
performed and passed satisfacto- 
rily. If all is well, the product is 
listed as Bluetooth qualified and 
may be sold as Bluetooth en- 
abled. 
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electronics will, by definition, include an In the OEM production environment, conformance test specifications that are 

interfering radio transceiver. Similarly, the tests have to vahdate performance in appropriate for their products' require- 

PCs have high-speed clocks or noisy bus- the shortest possible time. Production ments. 

es that can degrade module sensitivity. engineers need to select the subset of the To confirm that the device will operate 
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Notes: ACP (adjacent channel power); BT (Bluetooth); DH (Data High); EIRP (equhralent isotropically radiated power); 
PRBS (pseudo-random bit sequence); TX (transmitter). 
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over the Bluetooth specification's 10-m 
range, engineers will still need to meas- 
ure sensitivity and power levels. The con- 
formance specification requires engi- 
neers to measure receiver sensitivity as a 
BER of more than 1 ,600,000 bits at three 
frequencies. This test alone would take at 
least 25 sec using standard single-slot 
DHl packets and so, in practice, t he test 
will measure fewer bits even at a 
reduced number of frequencies. 

In addition to RF measurements, 
OEMs should perform a functional test. 
Tn the case of a Bluetooth-enabled digi- 
tal camera, for example, functional test- 
ing can include sending an instruction 
over the Bluetooth interface to activate a 
shutter release with flash. Engineers 
would need to create this command at a 
high level in the protocol stack (typical- 
ly the application level), and the test 
equipment would need to package the 
command into the Bluetooth format. 
Validating the camera's response to a 
high-level command would give the 
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In development you make raw transceiver measurements of a Bluetooth radio IC in isolation from 
the protocol stack. 



manufacturer confidence that the inter- 
face was functioning correctly, although 
it is not necessarily a guarantee of robust 
performance. □ 
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BACKGROUND TO BLUETOOTH 



/\s a standard for wireless communication 
between multiple devices, Bluetooth sup- 
ports voice and data. In 1994, Ericsson began 
to develop the standard at its Lund site in 
Sweden (Table A). The project was initially 
called MC Link (multicommunicator link). In 
1997, Ericsson approached other companies 
with a mutual interest in defining an open 
standard for a wireless link. In February 1998, 



five promoters-Ericsson, IBM, Intel, Nokia, 
and Toshiba-formed the SIG (Special Inter- 
est Group) to' promote the standard, which 
they renamed Bluetooth. 

The Bluetooth SIG announced the stan- 
dard on May 20, 1998. Two years later, more 
than 1800 companies had joined the consor- 
tium as adopters of the technology. The con- 
sortium's objective is to create a de facto 
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[Tiiriktype^ 
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Data rate 



Transmitter 
power 



Specification Comments 



SCO iiSynchronous connection 
oriented) 

ACL (Asynchrdnbus 
connection less ; linkg; 

ISM band, 2.402 to 
2.480 GHz, 79 channels- 
1-MHz spacing, 
hopping at 1600 hops/s 

2 FSK with OJ tianc^^ 
Gaussian filter, peak deviation 
175 kHz, modulation index 
0.28 to 035 : 

1 Mbaud gross, maximum 
net data rate 721 kbps, voice 
channel 64 kbps 

Class 1, P>OdBni,v 
ClassXP - 6ld t4dBm, 
Class 3, P <0 dBrh 



"Point-tOhppiiit full d^ 
circuit switdied; s^metric with ; 
iixed-ihterval slot res«Vation 

Momentar^connection, padtet I 
switching asynchronous with 
polling access ■ 

Now a common frequency plan 
including France, Spain, and 
Japan 



Actual data rate depends upon 
packet length, use of error 
correction, and encryption 



short-range wireless communication standard 
that all companies could use. In the autumn 
of 1999, the promoter group was expanded 
to nine companies, adding 3Com, Lucent 
Technologies, Microsoft, and Motorola. Al- 
though today the Bluetooth SIG standard is 
"owned" by the promoter group, it is expect- 
ed that the standard will become an IEEE 
standard (802.15) this year and remain fun- 
damentally the same. 

Bluetooth offe5 wireless communication 
between one or more devices over a 10-m 
range with a maximum gross data rate of 721 
kbps in the unlicensed 2.4-GHz ISM band. 
The purpose of the technology is to offer a 
low-cost, simple-to-use alternative to wired 
connections. As such, the potential user base 
is large and varied. 

The first adopters of Bluetooth are expect- 
ed to be mobile- phone manufacturers with 
wireless headsets. Mobile phones could also 
interface with a Bluetooth-enabled PCs to ex- 
change files or e-mail. A PC could have a 
wireless mouse and keyboard, and office 
printers could become Bluetooth enabled so 
that wireless printing is possible in any loca- 
tion. Other early adopters of the technology 
include PDAs (persona! digital assistants), 
LAN access points, digital cameras, and secu- 
rity-access cards. 
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SIG 

[special 

interest group]): "small-form factor, low-cost, short range radio links 
between mobile PCs, mobile phones and other portable devices." In 
other words, it's a wireless connection between PCs, peripherals, and 
portables that will let the devices share and synch information, without 
having to make a physical connection. 

Bluetooth's original backer is the Swedish mobile phone maker, 
Ericsson, which named the technology for a 10th-century king of 
Denmark, Harald Blatland, who unified the Danes and Norwegians. The 
spec's origins date back to 1994, when four companies joined Ericsson 
to develop the technology: Nokia, Toshiba, Intel, and IBM. Today, the 
Bluetooth SIG includes nearly 2,000 companies, and prototype devices 
are beginning to make their way into the marketplace. 

Although the idea behind Bluetooth (wireless communication between 
devices) has been around, it's the momentum behind this standard and 
the agreement among hundreds of vendors and manufacturers that has 
brought it to the verge of becoming a reality. The power of the 
Bluetooth vision begins to really emerge when you consider a world of 
devices intelligently connected and carrying much of their 
communication load automatically. 

Imagine having a Bluetooth-enabled phone or PDA on you. As you 
approach your home, you're able to control lighting, heating, even locks 
with your PDA. As you enter your home, you can use the same device to 
turn on the television set or the stereo system. Meanwhile, your 
refrigerator takes the initiative to update your shopping list. As you can 
see, the full picture includes a whole new level of automation where 
devices and appliances are programmed to communicate important 
information to each other, with or without human intervention. 

How it works 

Bluetooth uses the radio waves located in the frequency band of 2.4 
GHz (2400 to 2483.5 MHz), an increasingly popular (and crowded) slice 
of the spectrum. In this band, Bluetooth transmits voice and data at 
flows lower than 1 megabit per second. 

Bluetooth devices can function in two modes: 
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• circuit switched (tlie most common mode for voice 
communications, on land and wireless digital networks), and 

• packet switched (the mode for Internet data, as well as for higher 
bandwidth mobile communication systems on the horizon, like 
GPRS [General Packet Radio Service]). 

A device can use either one or both of these modes. In packet switched 
mode, connection is asynchronous with a rising flow of 57.6 Kbps to 721 
Kbps. In the second case, connection is synchronous with a flow of 64 
Kbps. 

Piconet and Scatternet 

A Bluetooth network (known as Piconet) can allow the interconnection of 
eight devices in a radius of 10 meters. This network can be fixed or 
provisional (a mobile or transitory network). In a Piconet, the Master 
seeks the devices in its entourage by emitting requests (broadcast). The 
slave answers with its Identification number. 

As many as 10 Piconets can overlap to form a Scatternet, linking up to 
80 Bluetooth appliances. Beyond this, the network saturates. Indeed, 
only 79 transmission channels are employed by the Bluetooth protocol, 
a limit based on the frequency. 

By default, Piconets transmit up to 10 meters (about 30 feet). However, 
you can increase it to 100 meters by increasing the power output of 100 
mW (milliwatts), as opposed to the 1 mW of default Bluetooth. However, 
compared to GSM (Global System for Mobile communications), which 
consumes between 1.5 and 2 Watts, this is still a weak signal. 
Manufacturers are working to make Bluetooth devices that adapt to the 
necessary proximity, so as not to consume more energy than is 
necessary. 

The Personal Area Network 

Bluetooth isn't designed to compete with 
wireless local area networks. Even its close- 
range throughput of 1 Mbps doesn't 
compare with the 11 Mbps that the 
emerging standard for wireless LAN, IEEE 
802.11, offers. 

Instead, Bluetooth's promoters are 
positioning it as the technology for the 
Personal Area Network (PAN), and are 
targeting appliances that don't require large 
flows — like printers, personal computers, 
and mobile phones. One concept that's 
been put forward is the mobile PAN: a 
communication device clipped to your belt 
could contain a GSM transceiver that 
communicates with the wider world. 

Meanwhile, the same device has a Bluetooth transceiver that 
communicates with your headset (replacing your mobile phone), your 
PDA, your MP3 player, allowing all these devices to communicate with 
each other and the larger world. 

Since it is not a very expensive technology (between $5 and $20 per 
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chip), it can easily be placed in many devices. Also, Bluetooth doesn't 
require an access point, unlike the traditional radio operator networks. 
It's well suited for mobile devices, since it can join a local Piconet 
quickly, as soon as the two devices are in a sufficient perimeter. 

And unlike infrared networks (like two Palm computers beaming each 
other), Bluetooth doesn't require you to align objects for them to 
communicate. 

Towards the intelligent whole 

Although most Bluetooth devices are still at the prototype stage, 
Ericsson has delivered the first Bluetooth-enabled phone, the Ericsson 
136. This GSM phone uses Bluetooth to communicate with the handset. 
Thus, a user could wear the headset and chat away while the handset 
was stashed away in a briefcase. Of course, since the power of the 
technology is in the network, a single Bluetooth device without others to 
communicate with is ... well, a start at least. 

Still, the momentum behind this de facto standard suggests a ripe 
market ahead: Cahners In-Stat Group predicts 1.4 billion Bluetooth- 
compatible devices by 2005. That's a conquest King Harald could be 
proud of. 

Albert Proust is co-authoring a book on WAP for O'Reilly Media, Inc.. 
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Sutecrtbe Now: 



Internet world is replete with buzzwords, trends, and rumors about the latest technologies coming to 
the fore. Ask anyone these days what the new darling of the Internet is, and they will tell you 
without a doubt that it's wireless technologies. Online journals, newsgroups, discussion forums, and 
print publications concerning the Internet are engaged in a furious exchange of opinions in which 
the pros and cons of various wireless data transmission protocols are alternately praised and reviled. 
One such protocol, simultaneously adored and despised, is Bluetooth (htt p://www .bluetooth.com). 

According to Cahners In-Stat Group (htt p;//www.instat.com ) in its July 2000 report, "Bluetooth 
2000: To Enable the Star Trek Generation," the manufacture of Bluetooth-enabled equipment will 
exceed one billion units by 2005, and the market will be worth some $5 billion. Frost & Sullivan 
( http://www.frost.com ) is equally optimistic. It forecasts global shipments of Bluetooth-enabled 
products to reach over 1 1 million units in 2001 and predicts $2.5 billion in revenues. 

The name itself is enough to start you wondering. When discussing the dry topic of data 
transmission protocols, we are used to throwing around terms such as TCP/IP, RIP, or PPP. 
Whether or not we can decipher the acronym, the terms have been used so often that most people 
have some idea of what we are talking about. But mention Bluetooth to the uninitiated and you're 
likely to be met with puzzled looks. 

A BIT ABOUT BLUETOOTH 

Bluetooth, named after the 10th century Viking king Harald Bluetooth, is a de facto data 
transmission standard developed by Ericsson and backed by a host of other technology companies 
that make up the Bluetooth Special Interest Group (including Ericsson, Intel, Puma Technology, 
Microsoft, Motorola, Nokia, 3Com, Lucent Technologies, and Toshiba). Bluetooth employs the 
unlicensed radio frequency (RF) portion of the electromagnetic spectrum in the 2.4-2.4835 gHz 
range. More simply, Bluetooth is a low-power, spread-spectrum technology that uses frequency- 
hopping to ensure speedy, short-range wireless data transfer of up to 720 kbps at a range of 30-100 
feet. Intended as a replacement for the short-range data cable, Bluetooth's original conception was 
as a wireless peripheral interface, linking print- ers, monitors, keyboards, and other peripheral 
devices to the CPU. However, the potential for the technology is much greater, offering the ability 
to link devices of different types, forming instant workgroups across multiple platforms in a 
seamless fashion. So how does Bluetooth work? 

The Bluetooth standard is a complex conglomeration of protocols arranged in a protocol stack, 
which, when diagramed, somewhat resembles a Dagwood-style sandwich. To put it more simply. 
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Bluetooth relies upon radio frequencies to transmit data, providing a xiniversal bridge betw^een 
devices on a network, or between devices from the outside and an existing network using a 
combination of circuit and packet-switching technologies. Bridges have the ability to link together 
different types of networks because a bridge delivers data based upon the MAC (Medium Access 
Control) address that is hard-coded into the network hardware by the factory that manufactures it, 
and it is unique for every device. This differs from other network devices, such as routers, that 
'deliver network data based upon routable protocols such as TCP/IP. Because bridges operate at a 
lower level of the protocol stack, standards like Bluetooth can link unlike devices within a local 
network. The data is, like all network traffic, divided into packets. However, because Bluetooth is 
designed to work in the RF environment-a very noisy portion of the electromagnetic spectrum-it 
employs the use of shorter packets for transmission, and combines this with fast frequency-hopping 
to ensure a fairly robust connection. 

When a message is sent over a Bluetooth connection, each packet is transmitted on a different 
frequency within a range of 2.4-2.4835 gHz. After the first packet is transmitted, the Bluetooth 
controller hops to a different frequency before sending out the next packet. The determination of 
which frequency within the given range will be used to start packet transmission is semi-random 
and is controlled by the Bluetooth Radio portion of the protocol stack. This frequency remains fixed 
for the duration of each packet. However, once the initial transmission frequency is chosen for the 
first packet, the remaining frequencies are cycled through for each subsequent packet in a 
determined fashion. This is known as the phase. 

BLUETOOTH IS SOCIAL 

When two or more Bluetooth-enabled devices are within range of each other, they automatically 
start communicating. Each Bluetooth-enabled device periodically broadcasts an inquiry message to 
see if there are any other Bluetooth devices in the area. If there is a response from another device, 
the originator of the inquiry message becomes the Master imit and the responder becomes the Slave. 
This arrangement is completely dependent upon which device is the first to send the inquiry 
message out when it comes within range, and does not resemble a client/server relationship. After 
this initial contact, the Master sends the slave(s) information about how they will communicate (i.e. 
the initial frequency and phase). These ad hoc networks are called Piconets. Collections of Piconets 
form Scattemets. Bluetooth supports point-to-point as well as point-to-multipoint links depending 
upon the number of devices within conununication range. In each case, the connections are peer-to- 
peer. 

Bluetooth can send data along four different channels simultaneously. Included is an asynchronous 
data channel (meaning packets are not sent out in pre-selected timeslots governed by the processor 
clock, but rather whenever there's an opportunity), and up to three simultaneous synchronous voice 
channels, or a combination channel, simultaneously supporting asynchronous data and synchronous 
voice. Each synchronous voice channel can support transfer rates of 64 kbps, and the asynchronous 
channel can support a bi-directional (two-way) asymmetric link of up to 721 kbps in either direction 
while permitting 57.6 kbps in the return direction. 

So what does all of this have to do with libraries and information professionals? A lot, if the push to 
promote the standard is successfiil. 

WILL LIBRARIES DEVELOP A TASTE FOR BLUETOOTH? 

Imagine an environment where users enter the library with their personal digital assistants (PDAs) 
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and are instantly connected to the network. They can pull up their records, search proprietary 
databases and the Web, check email, download information, and even check out materials from the 
stacks without ever having to stop at the checkout desk. All of these things are theoretically 
possible using the Bluetooth standard. Bluetooth-enabled networks have the potential to allow 
libraries to offer the kind of value-added services often held up as the holy grail of mission 
statements. 

In Ken Vamum's insightful article entitled "Information at Your Fingertips: Porting Library 
Services to the PDA," appearing in the September/ October 2000 issue of ONLINE, he illustrates 
how Ford Motor Company's corporate library is taking the initiative in porting library services to 
handheld devices, such as the PDA. The article demonstrates precisely how the engaged and aware 
information professional is finding new avenues for reaching out to users. Vamum explains how the 
library has effectively employed a third-party software package to translate Web pages into PDA- 
friendly files that users can download and take along with them on trips away from the office. This 
technology allows users to view documents, check and respond to email messages, and even fill out 
online forms. The drawback, of course, is that the user must return to the office and interface the 
PDA with a PC in order to synchronize the devices and actually transmit the email, form, etc. The 
PDA itself is not connected online and does not allow for real-time operation. 

Now, take that scenario and replace the old PDA with a new Bluetooth-enabled PDA. Then suppose 
traveling users find themselves at a hotel, airport, or library with a Bluetooth-enabled network 
connected to the Internet. Our users can now not only respond to email messages, but send them as 
well. They can conduct research and download updated documents. They can even use their PDAs 
to make phone calls. In short, the user has been given the type of information access that would 
have been unimaginable just a few years ago. 

BLUETOOTH IN TRADITIONAL SETTINGS 

Even the more traditional academic or public libraries could. reap the benefits of a Bluetooth- 
enabled network. Librarians at the reference desk assisting patrons in their research could directly 
beam the results to the patron's PDA, avoiding the cost of printing out the documents. Patrons with 
Bluetooth enabled devices connected to the library network could work together in ad hoc user 
groups, sharing information electronically. Library instructional sessions could be greatly facilitated 
by turning a patron's personal device into an instant workstation, eliminating the need for the library 
to purchase and maintain expensive computer labs. Network printers could be placed throughout the 
library for those who wish to obtain printouts without the restrictions that come with traditional 
network cables or the line-of-sight problems that accompany devices using infrared. A prototype 
description of Swedish rail traffic in the future (htt p://www.swedetrack.se/usblue2.htm ) proposes 
placing Bluetooth units at public libraries close to train stations to be used as passenger interfaces. 

LEXIS-NEXIS has teamed up with a primary developer of the Bluetooth Standard and member of 
the Bluetooth SIG, Red-M, a subsidiary of the Dutch company Madge Networks, to launch m-news. 
With content from LEXIS-NEXIS, m-news will provide subscribers with email updates and 
hypertext links to stories located on the Red-M Web site that detail Bluetooth industry 
developments. Registration is required but the service is fi-ee 
( http://www.redm.com/aboutred/newsroom/content.asp?Article=21 ). 

And if all of that sounds too good to be true, you may be right. 

BLUETOOTH MAY HAVE PROBLEMS AT ITS ROOT 
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The potential for Bluetooth is enormous, but its road to acceptance has been rife with criticisms and 
obstacles, some of which are substantial indeed. First there is the issue of cost. The original model 
developed by the Bluetooth SIG in 1998 called for a figure of $5 to integrate Bluetooth radio 
transceivers and link-level controllers into hand-held devices. The reality has been more in the 
range of $50 for the components, or slightly less if purchased in large quantities. And this is the 
price paid by the original equipment manufacturers (OEMs). Undoubtedly, by the time the device 
reaches the market, the price will be considerably higher. This has effectively put it out of the reach 
of most consumers. The inflated prices, however, are not the result of corporate greed, but more the 
unpredictable consequence of the technical difficulty of producing the chips and the resulting size 
of the chip being somewhat larger than anticipated. 

Another significant problem is that of interference. As Joe Wilcox, staff writer for CNET 
News.com notes in his September 15 article, "As Bluetooth Nibbles, Competition 
Lurks" ( http://news.cnet.com/news/0-lQ03-200-2784702.html ). the issue of frequency interference 
could potentially harm Bluetooth a great deal. Because Bluetooth uses the unlicensed radio portion 
of the electromagnetic spectrum, transmissions in that band must compete with industrial 
microwave ovens, stadium lights, garage door openers, cordless telephones, and virtually any 
wireless household appliance, even baby monitors. More detrimental to the long-term health of the 
Bluetooth standard, however, is its interference with two other wireless standards using the same 
2.4 gHz band that are older and more established: that of the 802.1 IB and the HomeRF. While 
these standards lack the catchy name and media hype that Bluetooth currently enjoys, 802.1 IB 
allows portable electronic devices to connect to an existing network at distances up to 300 feet 
rather than the paltry 100 feet that limits Bluetooth. Additionally, HomeRF recently won a ruling 
from the FCC that allows it to expand its bandwidth to 5mHz (up fi-om ImHz), effectively 
increasing transmission speeds to 10 Mbps. While there is room for these standards to operate in a 
complementary fashion within a wireless network environment, another challenge rears its head: 
compatibility. 

The bickering over who has control over various portions of the spectrum gets even uglier when 
dealing with the unlicensed portion that Bluetooth and other standards exploit. There is little that 
the FCC can do to regulate this area and still preserve the integrity of maintaining an open portion 
of bandwidth. To get around some of the interference problems, both HomeRF and Bluetooth use 
frequency-hopping. In contrast, the 802.1 IB standard has developed around a direct-sequence 
model in which only one fi-equency is used for transmission. The use of these two different methods 
introduces incompatibility between devices. A frequency-hopping Bluetooth device and a direct- 
sequence 802.1 IB device would not be able to communicate with each other. 

Add to that the security problems inherent in the Bluetooth standard, and the outlook appears grim. 
There is a security layer within the specification for Bluetooth, but by all accounts, it is easily 
misunderstood and prone to confiision. As Wilcox reports, an analyst with Gartner, a leading 
Internet industry consulting firm states, "Bluetooth is a disaster waiting to happenEthe specs cover 
(security), but unless you know what you're doing, it's possible to implement the spec in such a 
fashion (that) you aren't doing anything worthwhile." 

IT TAKES TWO TO TANGO 

The rollout of Bluetooth-enabled devices has experienced many delays as a result of some of these 
issues. When the Bluetooth SIG was first formed, the company fiilly expected to see widespread 
implementation by Christmas of 2000. Unfortunately, it has been only recently that Bluetooth- 
equipped devices have begun to trickle out of the development labs and into the hands of 
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consumers. Even so, there are not enough Bluetooth products around to make it a worthwhile 
investment. One Bluetooth device is no good-you really need at least two to play. Yet it is 
important to bear in mind that these problems are not insurmountable. Dozens of companies have 
significant resources sunk into the development of Bluetooth. To abandon it would represent a 
tremendous loss of time and money. While the future of the technology is by no means secure 
(there are a lot of kinks to work out), you can rest assured that much effort will go into its continued 
development and promotion. We'll see within the next few years if Bluetooth will sink its teeth into 
the information industry, or bite itself in the butt. 



Harald Bluetooth 

Harald Bluetooth, son of Denmark's first king, Gorm the Old, from whom the present Danish 
queen, Margarethe II, traces direct descent, did not have blue teeth. Instead, the name refers to a 
great man with a dark complexion. The Danish word for blue, bla, also meant dark and the words 
for man, mand, and tooth, tand, sound much the same. Harald Bluetooth is credited with 
Christianizing Denmark, Norway, and parts of Sweden and with uniting the countries into one 
kingdom. At the time of his rule, somewhere between 940 and 980 AD, southern Sweden was part 
of Denmark. In southern Sweden is the city of Lund, which is where Ericsson developed the 
Bluetooth technology. According to Ericsson in its discussion of Harald Bluetooth 
( http://bluetooth.ericsson.se/bluetootht7beginners g /default.asp?page=2 \ "One of his skills was to 
make people talk to each other..,.," hence the choice of Bluetooth to name this communications 
standard. If you're ever in Jelling, Denmark, you can view the rune stone Harald Bluetooth raised in 
honor of his parents. There's another, vastly newer, rune stone dedicated to Bluetooth himself It's 
outside Ericsson's Mobile Communications office in Lund. 

Maryellen Mott Allen (mallenf^Mh, usf.eciu) is Instructor Librarian, University of South Florida 
Tampa Campus Library, 

Comments? Email letters to the Editor at marydee(^infotoday. com , 

[infotoday.com] [ONLINE] [Current Issue] [Subscri ptions] IXopJ 

Copyright © 2001, Information Today, Inc. All rights reserved. 
custserv@infotoday.com 



http://www.onlinemag.net/OL2001/allen5_01.html 



12/19/07 



^ Performance Evaluation of the 

^ Bluetooth-based Public Internet Access Point 



Yujin Lim^ Jesung Kim, Sang Lyul Min, and Joong Soo Ma* 

Department op Mechanical Engineering, University of Seoul, Seoul, Korea^ 
School of Computer Science and Engineering, Seoul National University, Seoul, Korea 
Information and Communications University, Taejon, Korea^ 

yuj inOuos . ac . kr j skimQarchi . snu . ac . kr syminOdasdelion . sdu . ac . kr j smaOica . ac. kx 



Abstract — Recently^ Bluetooth has been regarded as a 
promising Bolution to an inexpensive wireless connection. 
Although initial application of Bluetooth technology has 
been focused mainly on replacing cables between hand-held 
devices, general wireless telecommunication such as public 
Internet access via a Bluetooth^equipped device is expected 
to be one of the most popular applications in the near fu- 
ture. However, it is not well understood whether perfor- 
mance of Bluetooth- based systems is sufficient for such an 
application. In this paper, we present preliminary results of 
performance evaluation of a Bluetooth- based Internet access 
point. The evaluation is based on simulation of an Internet 
access model consisting of a Bluetooth-based network ac- 
cess point and a number of Bluetooth-equipped notebook 
computers. The simulation results indicate that Bluetooth 
provides performance comparable to the fastest dial-up mo- 
dem even when a number of users share a single Bluetooth 
radio unit. Better performance is expected when more than 
one Bluetooth radio unit are employed such that each unit 
services different users concurrently. However, Bluetooth 
units in a single radio range (about 10m) Interferes each 
other since the channels established by each unit occasion- 
ally collide at the same frequency band. This paper analyzes 
the impact of such interference based on an analytical model 
of inter-channel interference. The analysis shows that the 
performance improves as the number of channels increases 
up to 40. We expect the proposed inter-channel interference 
model is useful in the design of systems facilitating multiple 
Bluetooth units. 



I. iNTRODCCTiON 

Interconnection of consumer devices has been increas- 
ingly important as the use of hand-held devices sudi as 
PD.Vs and celluar phones becomes increasingly popular. 
In the past, these devices were usually connected via a se- 
rial cable that requires physical wiring between two devices 
before they can excliange information. To avoid such incon- 
venience, a wireless communication technology has highly 
been demanded by users. Bluetooth is one of such technolo- 
gies and especially attractive in the enviromnent of hand- 
held devices since a low cost is an important requirement 
of sucli a technology [1]. Due to its low cost. Bluetooth 
is expected to be embedded in many consumer devices in 
the near future. Combined with the demand for access to 
the Internet everywhere in pub he places, a Bluetooth- based 
public Internet access point is expected to be popular. 

Wliile protocol models for Bluetooth- based access net- 

This research was supported in part by the Ministry of Education 
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Basic Research Program (for the woman scientists) of the Korea Sci- 
ence & Engineering Foundation. 



works have been proposed in the literature [2] [3], their per- 
formance is yet to be known. In this paper, we present a 
sinmlation model of Internet access based on the Bluetooth 
technology. The model consists of an Internet access point 
and a number of user devices each equipped with a Blue- 
tooth radio. To evaluate the perfonnance of the model, 
we have developed a simulator that accurately models the 
behavior of each user's requests to Internet access and ac- 
tions occurred in the Internet access point to service the 
requests. Since the radio in the Internet access point is 
shared by multiple users, a suitable scheduling policy is 
necessary to select which user will be serviced next. A plain 
round-robin policy seems to be a good choice since it is sim- 
ple to implement yet provides fairness. We also consider 
two other scheduling policies called a weighted jvund-ivbiu 
and a multi-level round-robin. Tlie simulation results show 
that both policies improve the performance by up to 35% 
over the plain round-robin policy. 

Performance can further be improved by facilitating nml- 
tiple Bluetooth radios in the Internet access point. It would 
be ideal if the performance boosts up to N times when N 
Bluetooth radios are used. However, since more than one 
radio may use the same carrier band due to the nature of 
FVequency Hopping Spread Spectrum (FHSS) [4], the effec- 
tive performance is less than N times especially when N 
becomes larger. This paper analyzes the performance of a 
Bluetooth system with nmltiple radios using a probabilistic 
model reflecting the interference. 

This paper is organized as follows. The following sec- 
tion describes the Internet access model and the simula- 
tion methodology. Section UI presents the simulation re- 
sults along with detailed analysis. Section IV analyzes the 
impact of multiple Bluetooth radio units in the Internet 
access point. Finally. Section V gives concluding remarks. 

11. Evaluation Model and Methodology 

A Bluetooth-based Internet access point is a system that 
provides Bluetooth-equipped devices with access to the In- 
ternet. It consists of a Bluetooth radio unit through which 
data communications occur with user devices, and an in- 
terface to tlie wire- based network infrastructure leading to 
the Internet. The main role of the Internet access point is 
to establish a wireless connection to each user device and 
forward user's packets to/from the wired network. 

A Bluetooth-based Internet access point may have either 
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a single or multiple radio units. Also, tlie radio units may 
act as a master or a slave. Tliis gives us a design space 
encompassing four possible combinations: (1) single slave 
unit, (2) single master unit, (3) multiple slave units, (4) 
multiple master units. In the first combination, the Inter- 
net access point acts as a slave while each user device acts 
as a master establishing it's own piconet to connect to the 
Internet access point. In this setup, the total bandwidth 
of the radio link is shared by all of the user devices. How- 
ever, this design requires the slave unit to switch from one 
piconet to another, which takes up to one frame. This over- 
head is significant when switching occurs frequently, e.g., 
in the order of a few frames. 

The second design choice is the Internet access point with 
a single radio unit that acts as a master of a piconet with 
all user devices as slaves. Wlien the radio is in the master 
mode, it controls all the slaves participathig in the piconet 
by determining which slave exchanges data with the mas- 
ter. This design is more efficient than the first design since 
the overhead of piconet switching is not present. 

The remaining two designs are extensions of the two ini- 
tial designs with additional radio units in the Internet ac- 
cess point. This allows load-sharing between radio units 
and hence improves both the total bandwidth and the max- 
imum number of users, at the costs of additional radio 
units. However, multiple radio units may interfere each 
other by occasionally colliding at the same frequency band, 
whose performance impact is analyzed in Section IV, 

In the simulation, we assume the second design. We 
also assume that the number of slaves is linuted to seven 
in order to remove the effect of parking that is required 
when more than seven slaves are to be connected to a mas- 
ter. We focus on the throughput and delay per user in a 
steady-state environment where no users join or depart the 
piconet. For the evaluation, we have developed an event- 
driven, packet-level simulator using PARSEC developed at 
UCLA as a successor to Maisie [5]. 

As for the Internet access model, we use a closed queuing 
simulation model that processes Internet web surfing traffic 
as shown in Figure 1. In this model, a user with a notebook 
generates traffic by clicking on the screen after consuming 
a UserThiiikTime. The user's request is inserted into a up- 
load queue in which the transmission is delayed until the 
master's polling is received. This delay is called a Bluet ootti 
upload scheduling delay and dependent on the scheduling 
policy of the master. After the upload scheduling delay, 
the notebook that is polled by the master sends the user's 
request to the Internet Access Point(AP) and the AP for- 
wards the request to the Internet. lutenietAccessTijne is 
the time for the AP to receive the user-requested data from 
the Internet since the request is submitted. When the re- 
quested data is ready, the data is inserted into the down- 
load queue and stays there until the corresponding note- 
book is polled. This delay is called a BluetooUi download 
scheduling delay and also affected by the sclieduling policy 
of the master. At this time, AP performs segmentation if 
necessary based on the length of the message. 

The packets used in tlie experiments include NULL and 




Fig. 1. Bluetooth simulation model 



TABLE I 
Parameter values for experiment 



Parameter 


Average Values 


Message Length 


[5 Kbytes, 50 Kbytes, 250 KBytes 
500 Kbytes, 1000 Kbytes] 


IntemetAccessTime 


[0.5s, Is] 


UserThinkTime 


[O.ls, Is, 2s, 3s, 4s, 5s] 



POLL packets for control data transmission, and DHl, 
DH3, and DH5 packets for user data transmission. We 
assume fixed-length upload data and variable- length down- 
load data reflecting the asynunetric nature of the Internet 
traffic. The parameter values used in the simulation are 
shown in Table I. The IntenietAccess Time and the User- 
ThinkTime are random variables distributed exponentially 
with averages shown in the table. The message length is 
also a random variable, distributed unifonnly. Each sinm- 
latioa is performed for a window of 24 hours. 

We measure the performance by throughput and delay. 
The throughput is defined as the rate of data transmitted to 
a slave in a time unit. As for the delay, two measurements 
are considered: completion delay and user delay. The user 
delay is defined as the time between the user's click and 
the arrival of the first packet of the requested data. It 
is equal to the sum of Bluetooth upload scfteduling delay, 
IntenietAccessTime, and download scheduling delay. The 
completion delay is defined as the time between the user's 
click and the arrival of the last packet of the requested 
data. The completion delay represents the time until the 
requested service is completed. 

As mentioned before, the Bluetooth upload and down- 
load scheduling delays are affected by the scheduling policy 
of the master. In Bluetooth specification 1.0. a round-robin 
(RR) is implicitly assumed as the underlying scheduling 
policy. In an RR pohcy, a master polls its slaves one by 
one in a fixed order, A slave is allowed to transmit a mes- 
sage in a designated slot only when it has been addressed 
by the master in the preceding slot. Thus the polling se- 
quence of the master is critical to the Bluetooth scheduling 
delay. The RR policy is fair in the sense that each user re- 
ceives the same number of polls. Although it seems fair, a 
slave with download data should wait for other slaves even 
when the other slaves do not need to be serviced. 

In this paper, we consider two other scheduling poli- 
cies to improve the delay: weighted wuud wbin (weighted 
RR) and multi-level rvund robin (nmlti-level RR). In the 
weighted RR, the master polls a slave up to n times suc- 
cessively when there is data that needs to be transmitted 
to the slave, while slaves with no data is polled only once. 
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Fig. 2, Throughput per user 

This policy improves the completion delay as we will see 
in the next section. On the other hand^ the multi-level RR 
can improve the user delay, as well as the completion delay 
by grouping the slaves into two classes, one consisting of 
slaves with download data and the otlier consisting of slaves 
with no data. In this policy, the master polls all the slaves 
belonging to the first class up to n times successively, prior 
to polling the slaves belonging to the second class, which 
are polled only once as in the case of the weighted RR. 

III. Eerformance Evaluation 

This section presents the simulation results based on the 
Internet access model described in the previous section. 
Figure 2- a shows the throughput per user for various num- 
bers of users and UserThinkTimes (denoted as UTT) in the 
Internet access model where the average message length is 
5 Kbytes and Inter-netAccessTime is 1 second in average. 
As we can see from the figure, the throughput is largely 
independent on the number of users when the piconet is 
not overloaded. Figure 2-b shows simulation results where 
the average message length is varied from 5 Kbytes to 1000 
Kbytes while UserThinkTimes is fixed to 2 seconds. In 
contrast to the previous results, when the average message 
length exceeds 250 Kbytes, throughput per user decreases 
by up to the ratio of 1 /n as the immber of users increases to 
n. However, it still outperforms the fastest dial-up modem 
(56 Kbps) in the marketplace even when a single Internet 
access point is shared by seven users. 

Figure 3 shows the performance in terms of delay. Fig- 
ure S-a sJiows the completion delay for various message 
lengths ranging from 5 Kbytes to 1000 Kbytes. The com- 
pletion delay increases up to 50 seconds as the number of 
users increases when the average message length is 1000 
Kbytes due to the heavy traffic. However, when the av- 
erage message length is below 5 Kbytes, the completion 
delay is less than 5 seconds regardless of the number of 
users. Figure 3-b shows the measurement of user delay in 
the same environment. In contrast to the completion de- 
lay, variation of user delay is very small for the range of 
message lengths we consider. Moreover, most of the user 
delay is due to the IntemetAccessTxme whidi is fixed to 1 
second in the simulation. The above results indicate that 
the Bluetooth- based Internet access service is feasible in 
terms of delay as well as throughput. 

In tlie previous experiments, it is assumed that the 
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(a) Message length = 5 Ktrytes (b) Message length = 50 Kbytes 

Fig. 4. Completion delay in weighted RR 

round-robin is the underlying scheduling policy. In the 
following, we present the simulation results for the other 
two pohcies relative to the round-robin assuming Inteme- 
tAccessTime and UserThinkTime are 0.5 sec and 1 sec in 
average, respectively. Figure 4 shows the completion de- 
lay of weighted RR normalized to RR for various numbers 
of successive polls for eacli user, denoted as n. The results 
show that t!ie weighted RR policy improves the completion 
delay by up to 15% when the traffic is low, as shown in Fig- 
ure 4-a. When the traffic is heavy, the improvement is even 
more evident as shown in Figure 4-b, where improvement 
is by up to 20%. Similar results are observed for other val- 
ues of parameters, although they are not included in this 
paper. 

However, weighted RR increases the user delay although 
it improves the completion delay. Figure 5 shows the mea- 
surement of the user delay as well as the completion delay, 
both of which normalized as the completion delay of RR. 
When the load is low, increase in tlie user delay is marginal 
as shown in Figure 5-a. However, when the piconet is over- 
loaded, the user delay increases by up to 24% compared to 
RR as shown in Figure 5-b. Note that the increase of the 
user delay is relatively small compared to the reduction in 
the completion delay. Overall, weighted RR policy gives 
performance improvement of up to 20% compared to RR. 

The delay of weighted RR can be improved by giving 
priority to the users with download data as explained in 
Section 11. Figure 6 shows the completion delay of the 
nmlti-level RR normalized to the delay of RR. The figure 
shows that weighted RR improves the completion delay 
by up to 25% when the load is high, and by up to 16% 
even when the load is low. From the results, we can notice 
that multi- level RR is even more efficient than weighted RR 
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(a) Message length = 5 Kbytes (b) Message length - 50 Kbytes 

Fig. 6, Completion delay in mult i- level RR 

especially in aii overloaded situation. The results also show 
that the best perforniaiice is achieved when the parameter 
value of Ti is set properly based on the transaction unit. 

Figure 7 shows the results of the user delay along with 
the coiupletioa delay. Similarly to weighted RR, when the 
load is low, difference in the user delay is marginal. How- 
ever, when the load is high, the user delay increases by 
up to 15%. Note that this number is much smaller than 
t!je case of weighted RR, where the increase is by up to 
24%. The results show that the multi-level RR improves 
the completion delay better than weiglited RR witli smaller 
increase in the user delay. Thus, in the Internet web surfing 
environment with burst traffic, scheduling policies based on 
a transaction unit such as the weighted RR and the multi- 
level RR are better than policies based on a frame unit 
sudi as the pure round robin. 

IV. Analysis on Inter-chankel Interference 

In the previous sections, a single Bluetooth unit in the 
Liter net access point is assumed to service several users by 
forming a piconet consisting of all tlie users and the Inter- 
net access point. In this setting, all piconet members share 
a single Bluetootli chauinel under the control of the mas- 
ter of the piconet. A Bluetooth channel follows a unique 
frequency hopping sequence determined by the Bluetooth 
address of the master. Since different Bluetooth channels 
use different frequency hopping sequences, more than one 



1 2 3 4 s e 7 
numbvr of nun 



1 2 3 4 5 fl 7 
n ot uton 



(a) Message length = 5 Kbytes (b) Message length = 50 Kbytes 
Fig. 7. User delay in multi-level RR 

Bluetooth cliannel can co-exist in a single Bluetooth cell. 
This gives a design choice of facilitating multiple Bluetooth 
units in a single Internet access point. However, multiple 
chaimels interfere with each other by occasionally using 
the same frequency band. Specifically, there are 79 differ- 
ent frequency baiids defined in the Bluetooth specification 
[6] and the probabiUty of two independent chaimels us- 
ing the same frequency band at any given time is 1/79, 
If both channels transmit a message simultaneously when 
this happens, a coUision occurs and eventually the message 
is garbled. 

Of course, Bluetooth has a mechanism to detect if a 
message is garbled and retransmit it if so. On the receipt 
of a message, the recipient sends the acknowledgement to 
the sender, usually piggybacking on the next message. If 
the sender does not receive a proper acknowledgement, the 
message is retransmitted, usually at the next hop. Note 
that Bluetooth does not require a back-off medianism to 
avoid repetitive collisions on retransmission, in contrast to 
other MAC protocols such as AtOHA since the probability 
of coUision at the next hop is independent of the collision. 
This also simplifies the probabilistic model of collisions as 
given in the following. 

We begin our analysis with the probability of a message 
transmitted in a cliannel being garbled by another chaii- 
nel. For simplicity, we assume that eacli message occupies 
a single Bluetooth slot and all channels are aligned each 
other so that the start of each slot is synchronized. Un- 
der this assumption, the probability of a message being 
garbled by another channel is the product of two probabil- 
ities, the probability of two cliaunels hopping onto the same 
frequency band and the probability of a message being car- 
ried in a slot. The latter can be thought of as a normalized 
load carried over a channel including both new messages 
and retransmitted messages. If we denote this term as G, 
the probability of a message being garbled is given as G/79. 
Then the probability of a message not being garbled when 
there are N channels with the same cliaracteristic, is equal 
to the probability of a message not garbled by any of - 1 
channels. Hence, we get 



Pnoco»»ion{N) = (l-C/79)'^ 



(1) 



In addition to the message, the corresponding acknowl- 
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edgeinent also needs to be transmitted without being gar- 
bled in order that a message is regarded as transmitted 
successfully by the sender. If we ignore the case of possible 
forward error correction and assume that the probability 
of an acknowledgement being garbled is the same as a mes- 
sage being garbled, the probability of a transmission being 
successful is: 

P{N) = Pn.conuion(Ny = (1 - C?/79)20>'-^) (2) 

Given the probability of a transmission being successful 
P{N) and the carried load G, we obtain the ratio of mes- 
sages transmitted successfully on a channel, i.e.. through- 
put, by multiplying G by P(N), 

(3) 



5 = GP{N) = G(l - G/79f^^-^^ 



The aggregated throughput of all of N cliannels, i.e., the 
throughput of the Internet access point, is given simply as 
S nmUiplied by N: 

S{N) = NGP(N) = NG(l - G/79f^^-'^ (4) 

The relationship between 5 and G for various N is shown 
in Figure 8. The figure shows that for smaller TV the 
throughput 5 increases almost linearly as the carried load 
G increases. However, for large TV, throughput does not 
increase beyond certain points, similarly to ALOHA [7]. 
For example, when TV is 128, 5 increases towards the max- 
imum value until G reaches about 0.3 and drops beyond 
this point. Such threshold can be obtained by differentiat- 
ing S by G. 



dS 



») 



=: (l-a/79)-*('^-*)-Ml-^G) 



(5) 



By settuig Elquation 5 equal to zero, we get G = 79/ (27V - 
1). Since G < 1 by definition, we get TV > 40. This implies 
that such threshold exists only when TV is greater than 40. 
Thus the threshold Gmax is represented as follows: 



_ / 1 

— S 79 



if TV < 40 
otherwise 



(6) 



Gmax for ranges of TV is plotted in Figure 9-a. Replacing G 
in Equation C with Gmax-. we obtain the maximum through- 
put Smax(^) as shown in Figure 9-b. The figure clearly 
shows tliat the maximum throughput does not improve 



(a) Carried load (b) Maximum throughput 

Fig. 9. Maximum throughput analysis 




Fig. 10. Alignment of channels 

when TV increase beyond 40. FVom the results, we can 
conclude that the performance of the Internet access point 
improves as the number of Bluetooth units increases up 
to 40 although the improvement becomes smaller due to 
inter-channel interference. 

Tlie previous analysis assumes that each message occu- 
pies a single slot and the channels are aligned with each 
other as shown in Figure 10-b (Case B). In this subsection, 
we try to relax the second assumption. When cliannels are 
not aligned as in the case shown in Figure 10-c (Case C), 
a message can collide by either of two messages in a chan- 
nel, increasing the probability of a collision. On the other 
hand, Figure lO-a shows the case where the acknowledge- 
ment cannot be garbled by the other channel, improving 
the probability of a transmissiori beiiig successful. Assum- 
ing that the three cases are generated randomly and that 
all the messages are carried over DHl packets, the proba- 
bility of eacl» case is given as follows: 




Iff = 0.2128, 
= II = 0.6160, 
= M = 0.1712 



(7) 



where Pi, P2, and pz represent the probability of two chan- 
nels being in Case A, Case B, and Case C, respectively, and 
h. TH. and / represent the length of the header of a DHl 
packet (126 /isec), the length of a DHl packet including 
the header (366 ^xsec), and the length of a slot (625 /isec), 
respectively. 

Applying binomial twice, we obtain the normalized 
throughput 5' (TV) as follows: 



xp^-'-^*'''^NG{l-G/79) 
xp*TVG(l-C?/79p 
xp^TVG(l-G/79)3> 
= TVG(l-G/79)''^-^ 

^N~\ /,V-l^ ^*V-l-i 



(8) 
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(a) aligned-channel model (b) unaligned-channel model 



Fig. 11. Comparison of both models (DHl) 
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Fig. 12. Throughput in on unaligned channels 

Figure 11 compares the previous model {aligned-channel 
model) and the relaxed model (unaligned- channel model). 
The figure shows that the difference between two models is 
marginal. It is due to the fact that the Case A (probability: 
0.2128) and Case C (probability: 0.1712) offset each other 
and Case B (probability; 0.6160) dominates, which is the 
same case as the previous model. 

In the case of DH3 or DH5, the equation remains un- 
changed but the probability Pi. P2, and pz are computed 
in a sliglitly different manner; 
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where m^"^ and rn^"^ are the size of a DH3 packet (1598 
psec) and the size of a DH5 packet (2862 ^isec), respec- 
tively. The results are shown in Figure 12. Since pz 
is greater compared to the case of DHl, the normalized 
throughput is reduced due to a larger collision probabil- 
ity. Note that this does not imply that the performance 
is reduced by using DH3 / DH5 instead of DHl, since 
the throughput shown in the figure is normalized by the 
throughput of a single channel using DH3 and DH5, re- 
spectively. In fact, the use of DH3 / DH5 improves the 
performance since the overhead of packetization is much 
less than DHl. From the results, we can notice that both 
models show similar characteristics and reflect the rela- 
tionship between the number of chaimels and the resulting 
aggregated throughput. 



V. Conclusion 

Today, access to the Internet is essential in every-day life. 
It is hard to think of business, research, and entertainment 
without the Internet. Therefore, it is a requirement, rather 
than an option, to facilitate functionality of Internet access 
in hand-held devices such as PDA for every whei^- Internet 
services. Since hand-held devices require low cost and low 
power consumption, Bluetooth has been regarded as one 
of the most promising solutions for a wireless connection 
between the user devices and the wired network infrastruc- 
ture. 

In this paper, we have presented preliminary results on 
the performance of a Bluetooth-based access network. In 
the performance evaluation, we have modeled a simple In- 
ternet access scenario and simulated while varying the val- 
ues of various parameters including user's think times, mes- 
sage lengths, and Internet access delay. The simulation 
results indicate that the Bluetooth- based access network 
provides performance of tens of Kbps to hundreds of Kbps 
depending on the number of users. This result is encour- 
aging since the Bluetooth- based access network gives per- 
formance significantly better than the traditional dial-up 
network without the tedious wire connection. The perfor- 
mance can be improved if multiple Bluetooth radio units 
are used in the Internet access point. We have shown that 
the performance improves as the number of Bluetooth units 
increases up to 40 based on an analytical model. 

As a future work, we plan to develop a more general 
Bluetooth simulation package including a traffic generator 
that reflects a variety of traffic such as ftp, e-mail, and 
name-card exchange. We expect the simulation package 
will allow us to evaluate various aspects of Bluetooth sys- 
tems including issues on scheduling policies, segmentation 
and reassembly, parking of user devices that are largely ig- 
noi-ed in this paper. We also expect thorough evaJuation 
with the new simulation tool would reveal possible causes 
of performance bottlenecks in the Bluetooth system. 
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Handheld devices are rapidly becoming an 
integral part of our daily lives, and many 
road warriors already carry a cell phone, 
palmtop, and laptop computer with them. In most 
cases, these devices do not have compatible data 
communication interfaces, or, if they do, the inter- 
face requires cumbersome cable connections and 
configuration procedures. An obvious solution is 
to get rid of the cables and use short-range wire- 
less links to facilitate on-demand connectivity 
among devices. An ideal solution would also be 
inexpensive, enabling of compelling applications, 
and universally adopted by device vendors. 

In 1998, five major companies (Ericsson, Nokia, 
IBM, Toshiba, and Intel) formed a group to create a 
license- free technology for universal wireless con- 
nectivity in the handheld market. The result is 
Bluetooth, a technology named after a 10th-cen- 
tury king who brought warring Viking tribes under 
a common rule. The Bluetooth specifications,'-^ 
currently in version 1.1, define a radio frequency 
(RF) wireless communication interface and the 
associated set of communication protocols and 
usage profiles. 

The link speed, communication range, and 
transmit power level for Bluetooth were chosen 
to support low-cost, power-efficient, single-chip 
implementations of the current technology. In 
fact, Bluetooth is the first attempt at making a 
single-chip radio that can operate in the 2.4-GHz 
ISM (industrial, scientific, and medical) RF band. 
While most early Bluetooth solutions are dual 
chip, vendors have recently announced single- 
chip versions as well. In this overview of the 
technology, I will first describe the lower layers 
of the Bluetooth protocol stack. I will also briefly 
describe its service discovery protocol and, final- 



ly, how the layers of the protocol stack fit togeth- 
er from an application's point of view. 

Bluetooth Specifications 

The Bluetooth 1.1 specification was released in 
February 2001. The specification consists of two 
parts: core and profiles. 

Core Specifications 

The core specification defines all layers of the 
Bluetooth protocol stack.' As shown in Figure 1, 
the Bluetooth stack differs from the classical 
seven-layer networking model in some ways. 
These differences are primarily to support ad hoc 
connectivity among participating nodes, while 
conserving power and accommodating devices 
that lack resources to support all layers of the clas- 
sical networking stack. 

The radio is the lowest layer. Its interface spec- 
ification defines the characteristics of the radio 
front end, frequency bands, channel arrangements, 
permissible transmit power levels, and receiver 
sensitivity level The next layer is the baseband, 
which carries out Bluetooth's physical (PHY) and 
media access control (MAC) processing. This 
includes tasks such as device discovery, link for- 
mation, and synchronous and asynchronous com- 
munication with peers. Bluetooth peers must 
exchange several control messages for the purpose 
of configuring and managing the baseband con- 
nections. These message definitions are part of the 
link manager protocol (LMP). The functional enti- 
ty responsible for carrying out the processing asso- 
ciated with .LMP is called the link manager. 

Bluetooth is unique in offering the front-end RF 
processing integrated with the baseband module. 
On-chip integration lowers the cost of the network 
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Figure IJhe Bluetooth networking stack and chip.The design supports the integration of an analog 
radio front end, signal-processing e/ements, and baseband controller on a single chip. 



interface, and the small size makes it easy to 
embed Bluetooth chips in devices such as cell 
phones and PDAs. A Bluetooth chip can be con- 
nected to its host processor using USB, UART, or 
PC-card interfaces. 

The Host Controller Interface (HCI) specification 
defines a standard interface-independent method 
of communicating with the Bluetooth chip. The 
software stack on the host processor communi- 
cates with the Bluetooth hardware using HCI com- 
mands. Since no hardware-specific knowledge is 
needed, the Bluetooth stack software can easily be 
ported from one Bluetooth chip to another. The 
HCI layer is part of the Bluetooth stack, but it 
doesn't constitute a peer-to-peer communication 
layer since the HCI command and response mes- 
sages do not flow over the air link. 

The logical link control and adaptation proto- 
col (L2CAP) specification can be viewed as Blue- 
tooth's link layer. Usually, L2CAP and layers above 
it are implemented in software. L2CAP delivers 
packets received from higher layers to the other 
end of the link. Bluetooth devices can establish an 
L2CAP connection as soon as they are in range of 
each other. A client device then needs to discover 
the services provided by the server device. 

The service discovery protocol (SDP) defines the 
means by which the client device can discover ser- 
vices as well as their attributes. The SDP design 
has been optimized for Bluetooth. It defines only 
the discovery mechanisms; the methods for access- 
ing those services are outside its scope. 

The RFCOMM specification defines a method of 
emulating the RS-232 cable connection on top of 
the Bluetooth airlink. RFCOMM supports legacy 



applications that use the COM port to communi- 
cate with the peer host For example, point-to- 
point (PPP) protocols expect a serial line interface 
firom the lower layer. Since PPP provides a pack- 
et-oriented interface to the higher layers, all pack- 
et-based network and transport protocols, includ- 
ing TCP/IP, can be supported on top of PPP. More 
efficient methods of running IP over Bluetooth are 
currently under development. 

Profile Specifications 

Vendors can use the services offered by the Blue- 
tooth stack to create a variety of applications. 
Because interoperability is crucial to Bluetooth's 
operation, the Bluetooth SIG has defined profile 
specifications to support it.^ The current specifica- 
tions include 13 profiles listed in Table 1 (next page). 

The profiles specify controller and stack para- 
meter settings as well as the features and proce- 
dures required for interworking among Bluetooth 
devices. All vendor implementations of these pro- 
files are expected to be interoperable. The Blue- 
tooth certification authority uses the profiles to 
test and certify compliance, and grants use of the 
Bluetooth logo only to products that conform to 
the methods and procedures defined in the profiles. 

Radio Front End 

The 2.4-GHz ISM band in which Bluetooth oper- 
ates is globally available for license-free use. 
Europe and the United States allocate 83.5 MHz 
to this band, but Spain, France, and Japan allo- 
cate less. To accommodate these differences, 79 
channels spaced 1 MHz apart are defined for 
Europe and the U.S., and 23 RF channels spaced 
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Table 1 , Profiles defined In Bluetooth LI specifications. 


Use case 

Generic access 


Description 

Generic procedures for discovery and link management of connecting to Bluetooth devices. 


Service delivery 


Features and procedures for a Bluetooth device application to discover services registered in other devices. 


Cordless telephone 


Features and procedures for interoperability betv^een different units active in a*'3-in-rphone. 


Intercom 


Requirements for supporting intercom functionality within a "B-in-T phone. 


Serial port 


Requirements for setting up emulated serial cable connections using RFCOMM between two peer devices. 


Headset 


End-user service requirements and interoperability features for Bluetooth devices implementing headsets. 


Dial-up networidng 


End-user service requirements and interoperability features for Bluetooth devices implementing dial-up networicing. 


Fax 


End-user service requirements and interoperability features for Bluetooth devices implementing fax services. 


UN access 


Definition of (a) how Bluetooth devices can access LAN services using PPP and (b) how the PPP mechanisms form a network. 


Generic object exchange 


Requirements for Bluetooth devices to support object exchange usage models. 


Object push 


Application requirements for Bluetooth devices to support the object push usage model. 


File transfer 


Application requirements for Bluetooth devices to support the file transfer usage model. 


Synchronization 


Application requirements for Bluetooth devices to support the synchronization usage model. 



1 MHz apart are defined for Spain, France, and 
Japan. Efforts are under way to open up the full 
width of the spectrum in Spain and France, as well 
as in Japan so that Bluetooth devices would func- 
tion worldwide. 

Bluetooth is a frequency-hopping spread-spec- 
trum system. This means that the radio hops 
through the full spectrum of 79 or 23 RF channels 
using a pseudorandom hopping sequence. The hop- 
ping rate of 1,600 hops per second provides good 
immunity against other sources of interference in 
the 2.4-GHz band. The link speed is 1 Mbps, which 
is easily achieved using a simple modulation tech- 
nique (Gaussian Frequency Shift Keying, or GFSK). 
A more complex modulation technique could 
achieve a higher rate, but GFSK keeps the radio 
design simple and low cost. 

The radio front end is usually the most costly 
part of a wireless network interface. In typical 
radio receivers, the RF filters, oscillators, and 
image-reject mixers process input signals at high 
frequencies. Such circuits require expensive 
materials. To keep costs down, Bluetooth recom- 
mends shifting the input signal to a lower inter- 
mediate frequency (IF, around 3 MHz), which 
allows on-chip construction of low-power filters 
using CMOS material. Shifting to low TF, howev- 
er, creates new problems, such as reduced receiv- 
er sensitivity. Recommended receiver sensitivity 
for Bluetooth is -70 dBm or better. The compa- 
rable number for IEEE 802. 11 Wireless LANs is 
about -90 dBm). Thus, for the same transmit 
power, the range for Bluetooth is shorter than it is 
for 802.11 WLAN. 



Piconets and Scatternets 

A set of Bluetooth devices sharing a common 
channel is called a piconet As shown on the left 
side of Figure 2, a piconet is a star-shaped con- 
figuration in which the device at the center per- 
forms the role of master and all other devices 
operate as slaves. Up to seven slaves can be active 
and served simultaneously by the master. If the 
master needs to communicate with more than 
seven devices, it can do so by first instructing 
active slave devices to switch to low-power park 
mode and then inviting other parked slaves to 
become active in the piconet. This juggling act can 
be repeated, which allows a master to serve a large 
number of slaves. 

Most envisioned Bluetooth applications involve 
local communication among small groups of 
devices. A piconet configuration consisting of two, 
three, or up to eight devices is ideally suited to 
meet the communication needs of such applica- 
tions. When many groups of devices need to be 
active simultaneously, each group can form a sep- 
arate piconet. The slave nodes in each piconet stay 
synchronized with the master clock and hop 
according to a channel-hopping sequence that is 
a function of the master's node address. Since 
channel-hopping sequences are pseudorandom, the 
probability of collision among piconets is small. 
Piconets with overlapping coverage can coexist 
and operate independently. Nonetheless, when the 
degree of overlap is high, the performance of each 
piconet starts to degrade. 

In some usage scenarios, however, devices in 
different piconets may need to communicate with 
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each other. Bluetooth defines a structure called 
scattemet to facilitate interpiconet communica- 
tion. A scattemet is formed by interconnecting 
multiple piconets. As shown on the right side of 
Figure 2, the connections are formed by bridge 
nodes, which are members of two or more 
piconets. A bridge node participates in each mem- 
ber piconet on a time-sharing basis. After staying 
in a piconet for some time, the bridge can turn to 
another piconet by switching to its hopping 
sequence. By cycling through all member 
piconets, the bridge node can send and receive 
packets in each piconet and also forward packets 
from one piconet to another. 

A bridge node can be a slave in both piconets 
or be a slave in one and a master in another.^ For 
example, consider a room full of people, where 
each person has a cell phone and a cordless head- 
set. When users speak into their headsets, only the 
cell phones paired with their headsets should pick 
up the signal. In this example, each headset and 
cell phone pair constitutes a separate piconet. Now 
suppose these users also want to send text mes- 
sages from their cell phones to one another. This 
will be possible only if all piconets are intercon- 
nected to form a large scattemet. 

The techniques for forming scattemets are still 
under development"* 

Inquiry and Paging 

Bluetooth uses a procedure known as inquiry for 
discovering other devices; it uses paging to subse- 
quently establish connections with them. Both 
inquiry and paging are asymmetric procedures. In 
other words, they involve the inquirer and the 
inquired (as well as the pager or the paged) devices 
to perform different actions. This implies that when 
two nodes set up a connection, each needs to start 
from a different initial state; otherwise, they would 
never discover each other. The profile specifications 
play an irnportant role here, defining the required 
initial state for each device in all usage scenarios. A 
symmetric procedure for establishing connections 
is an ongoing topic of research."* 

The inquiry and paging are conceptually sim- 
ple operations, but the frequency-hopping nature 
of the physical layer makes the low-level details 
quite complex. Two nodes cannot exchange mes- 
sages until they agree to a common channel-hop- 
ping sequence as well as the correct phase within 
the chosen sequence. Bluetooth solves this prob- 
lem simply by mandating the use of a specific 
inquiry-hopping sequence known to all devices. 
During inquiry, both nodes (one is the listener and 
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figure 2. ?\cor\^t (left) and scotternet (hghtj.The master device at 
the center of a piconet con serve up to seven slaves; niembers of 
two or more piconets are called bridge nodes, which support interpi- 
conet communication. 



the other is the sender) hop using the same 
sequence; but the sender hops faster than the lis- 
tener, transmitting a signal on each channel and 
listening between transmissions for an answer. 
When more than one listener is present, their 
replies may collide. To avoid the collision, listen- 
ers defer their replies until expiration of a random 
backoff timer. Eventually the sender device col- 
lects some basic information from the listeners, 
such as the device address and the clock offsets. 
This information is subsequently used to page the 
selected listener device. 

The communication steps during the paging pro- 
cedure are similar, except that the paging message 
is unicast to a selected listener, so the listener need 
not back off before replying. The sender also has a 
better estimate of the listener's clock, which enables 
it to communicate with the listener almost instan- 
taneously. Upon receiving an ACK for the paging 
message, the sender becomes the master and the 
listener becomes the slave of the newly formed 
piconet, and both nodes switch to the piconet's 
channel-hopping sequence. Later, if necessary, the 
master and slave roles can be swapped. 

The steps for admitting a new slave into an 
existing piconet are slightly more complex. The 
master can either start discovering new nodes in 
its neighborhood and invite them to join the 
piconet or, instead, wait in scan (listen) state and 
be discovered by other nodes. With both options, 
communication in the original piconet must be 
suspended for the duration of tHe inquiry and pag- 
ing process. The latency of admitting a new node 
into the piconet can be large if the master does not 
switch to the inquiry or scan modes frequently. 
This latency can be reduced only at the cost of 
some piconet capacity. The study of this trade-off 
is another topic of ongoing research. 
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Table 2, Channel throughput for different packet sizes. 



Packet size (in slots) 


Throughput in Kbps (with FEC) 


Throughput in Kbps (no FEC)* 


In slave In master 


In slave In master 


In slave In master 


direction direction 


direction direction 


direction direction 


1 1 


108.8 108.8 


172.8 172.8 


3 1 


387.2 54.4 


585.6 86.4 


S 1 


477.8 36.3 


723.2 57.6 



Low- Power Modes 

Bluetooth offers different low-power modes for 
improving battery life. Piconets are formed on 
demand when communication among devices is 
ready to take place. At all other times, devices 
can be either turned off or programmed to wake 
up periodically to send or receive inquiry mes- 
sages. When a piconet is active, the slaves stay 
powered on to communicate with the master. It 
is possible to switch a slave into a low-power 
mode whereby it sleeps most of the time and 
wakes up only periodically. 

Three types of low-power modes have been 
defined: 

■ Hold mode is used when a device should be put 
to sleep for a specified length of time. As 
described earlier, the master can put all its 
slaves in the hold mode to suspend activity in 
the current piconet while it searches for new 
members and invites them to join. 

m Sniff mode is used to put a slave in a low-duty 
cycle mode, whereby it wakes up periodically 
to communicate with the master. 

■ Park mode is similar to the sniff mode, but it is 
used to stay synchronized with the master 
without being an active member of the piconet. 
The park mode enables the master to admit 
more than seven slaves in its piconet. 

Piconet Channel 

As soon as a piconet is formed, communication 
between the master and the slave nodes can begin. 
The piconet channel is divided into 625-microsec- 
ond intervals, called slots, where a different hop 
frequency is used for each slot. The channel is 
shared between the master and the slave nodes 
using a frequency-hop/time-division-duplex 
(FH/TDD) scheme whereby master-slave and slave- 
master communications take turns. Slave-to-slave 
communication is not supported at the piconet 
layer. If two slaves need to communicate peer to 
peer, they can either form a separate piconet or use 
a higher layer protocol, such as IP over PPP (see 



Figure 1), to relay the messages 
via the master. 

At a 1-Mbps link speed, a 625- 
microsecond slot time is equiva- 
lent to the transmission time of 
625 bits. However, a single slot 
packet size in Bluetooth is only 
366 bits. This reserves enough 
guard time to let the frequency 
synthesizers hop to the next 
channel frequency and stabilize. Discounting space 
for the headers leaves 30 bytes for the user payload. 

Synclironous Link 

To transmit real-time voice, an application must 
reserve a slot in both directions at regular inter- 
vals. In Bluetooth terminology, this is called a syn- 
chronous (SCO) link. An SCO link can transport 
telephone-grade voice. The speech coder generates 
10 bytes every 1.25 milliseconds. Since a baseband 
packet can carry up to 30 bytes in each slot, only 
one slot in each direction is needed every 3.75 ms 
(or every sixth slot). The packet type that carries 
30 voice bytes is called an HV3 packet. This pack- 
et is transmitted without coding or protection, and 
is not retransmitted if it is lost 

To cope with bit errors when the channel condi- 
tions are not perfect, some forward error correction 
(FEC) should be added to the voice payload. An 
HV2 packet carries 20 bytes of voice plus 10 bytes 
of redundant data (2/3 FEC code). Since 20 bytes of 
speech is generated in 2.5 ms, the SCO link should 
reserve one slot in each direction every 2.5 ms (or 
every fourth slot). To cope with extreme channel 
conditions, the baseband specification also defines 
an HVl packet that carries only 10 bytes of speech 
and 20 bytes of FEC code. An HVl SCO link uses 
up the entire channel capacity. This means that all 
data transfer sessions will be suspended when an 
FfVl SCO connection is in progress. 

Asynchronous Link 

Data communication between a master-slave pair 
involves a different set of considerations. For 
example, the data payload must be protected by a 
cyclic redundancy check (CRC) so that the receiver 
can determine whether the received bits are in 
error When losses occur, the baseband layer should 
retransmit the data. Furthermore, to make efficient 
use of the piconet channel, slots should be allocat- 
ed on demand, instead of being reserved for the 
usage duration. A data path between a master-slave 
pair meeting all of these requirements is called an 
asynchronous data link (ACL). SCO links have pri- 
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ority over data, so ACLs can claim only unused 
slots. Only a single ACL can exist between a master 
and a slave. 

The master is responsible for distributing 
available slots among all ACLs. This scheme has 
two advantages: 

■ the master can ensure that the slave transmis- 
sions do not collide; and 

■ the slots can be allocated to satisfy the quality 
of service (QoS) requirement of each ACL. The 
master can grant more bandwidth to a slave by 
polling it more frequently or by changing the 
packet size. 

The baseband specification does not mandate the 
use of any specific slot-allocation scheme. Chip 
vendors can choose any policy that fits their tar- 
get applications. 

As with SCO packets, the payload size of single- 
slot ACL packets is limited to 30 bytes. After dis- 
counting space for the higher layer headers and the 
CRC, only 27 bytes are left to transport application 
data. When FEC is added, the available space goes 
down to 17 bytes. To improve channel efficiency, 
the baseband specification has defined multislot 
packets, which are three or five slots long and trans- 
mitted in consecutive slots. The transmitter stays 
fixed on a hop frequency during the length of pack- 
et transmission and skips over the missed hops after 
the transmission is complete. This reduces the effec- 
tive channel-hopping rate, but increases the chan- 
nel efficiency because of fewer hops. 

Table 2 shows the achievable throughput in the 
master-to-slave and slave-to-master directions as 
a function of packet size, with and without FEC. 
Although link speed is 1 Mbps. achievable aggre- 
gate throughput can range from 217.6 Kbps to 
780.8 Kbps. The presence of an HV3 or HV2 SCO 
link significantly reduces the achievable through- 
put of an ACL. 

Logical Link Control 
and Adaptation Protocol 

L2CAP can be viewed as the data plane of the 
Bluetooth link layer (see Figure 3). Because the 
baseband packet size is too small for transporting 
higher layer packets, a thin layer is needed for 
exporting a bigger packet size to the higher layers. 
While a number of generic segmentation and 
reassembly protocols could be used or adapted for 
use over ACLs, the Bluetooth SIG instead defined 
L2CAP, which is highly optimized to work in con- 
junction with the baseband layer. For example. 



Device I Device 2 




Figure 3. Lower part of stack. L2CAP con be 
viewed as the data plane of Bluetooth*s link layer. 



L2CAP does not support integrity checks because 
the baseband packets are already CRC protected. 
Likewise, it is assumed that the lower layer deliv- 
ers packets both reliably and in sequence. These 
two assumptions significantly simplify the design 
of segmentation and reassembly logic. The only 
caveat is that L2CAP will not work if used over 
any media other than the Bluetooth baseband. 

The multiplexing and demultiplexing of higher 
layer protocols is supported using channels, mul- 
tiple instances of which can be created between 
any two L2CAP endpoints. Each higher layer pro- 
tocol or data stream is carried in a different chan- 
nel. The L2CAP channels are connection oriented 
in the sense that they require an explicit phase to 
establish the channel, during which both ends 
choose a local name (channel identifier) and com- 
municate it to the other end. Subsequently, each 
packet sent over the channel is tagged with the 
channel identifier, which-within the context of the 
receiver-uniquely identifies the source as well as 
the protocol being transported over the channel. 

The L2CAP specification also defines a connec- 
tionless channel for supporting broadcast and 
multicast group communication, but this feature 
is not yet fully developed. 

Service Discovery Protocol 

Both ends of a Bluetooth link must support com- 
patible sets of protocols and applications to suc- 
cessfully exchange data. In some cases it may also 
be necessary to configure protocol and stack para- 
meter settings before applications can be started. 
Such configuration settings cannot be chosen sta- 
tically, since some parameters may require adjust- 
ment to match the features and services support- 
ed by the peer Bluetooth device. 

Bluetooth's SDP provides a standard means for 
a Bluetooth device to query and discover services 
supported by a peer Bluetooth device. SDP is a 
client-server protocol. The server maintains a list 
of service records, which describe the characteris- 
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tics of services hosted at the server. By issuing SDP 
queries, a client can browse all available service 
records maintained at the server or retrieve specif- 
ic attribute values from a service record. 

In addition to defining query and response pro- 
tocol formats, the SDP specification also defines 
a standard method for describing service attribut- 
es. Service attributes are represented using an 
<identifier, value> pair. The 1.1 specification 
defines some of the commonly used services, but 
developers have the freedom to define new sub- 
classes of the standard services or to create new 
services on their own. 

Since new service definitions do not require any 
coordination with the Bluetooth SIG numbering 
authority, it is necessary to ensure that two inde- 
pendently created service definitions do not con- 
flict. Collisions are avoided by associating each 
service definition with a universally unique iden- 
tifier (UUID) which is generated once at the time a 
service is defined. UUIDs of the services defined by 
the Bluetooth SIG are included in the assigned 
numbers document. 

If the client already knows the UUID of the ser- 
vice it is looking for, it can query the SDP server 
for specific service attributes. Alternatively, the 
client can browse the list of available services and 
select from the list. These are the only two search 
options supported in SDP. Although other IP-based 
service discovery protocols, such as SLP and Jini, 
provide richer service description schema and more 
powerful search capabilities, the Bluetooth SDP has 
two advantages: 

■ The majority of version- 1 . 1 -compliant Blue- 
tooth devices will be non-IP devices. Requiring 
them to support IP only for the sake of sup- 
porting SLP would be costly. 

■ SDP is optimized to run over L2CAP. Its limited 
search capabilities and non-text-based 
attribute-id and attribute-value descriptions 
lend an efficient and small footprint imple- 
mentation for small devices. 

SDP provides a mechanism only for retrieving ser- 
vice information from other devices. Methods of 
invoking those services are outside the scope of SDP. 

Link Manager Protocol 

Before a device can establish the L2CAP channel, 
the link manager must carry out a number of 
baseband-specific actions, such as piconet cre- 
ation, master-slave role assignments, and link 
configuration. These functions belong to the con- 



trol plane of the Bluetooth link layer and require 
the link manager to exchange LMP messages over 
the air link. Depending on the operating environ- 
ment, the link manager must adjust a number of 
piconet and link-specific parameters. For exam- 
ple, the peer-link controller can be instructed to 
switch to a low-power mode, adjust its power 
level, increase the packet size, and change the 
requested QoS on an ACL. 

Security can also be configured using LMP 
messages. Before a data or voice exchange can 
begin, Bluetooth devices should be able to 
authenticate each other. Likewise, transmission 
over the air link must be encrypted to provide 
protection from eavesdroppers. Both objectives 
are easy to achieve when a security association 
already exists between a pair of devices. The link 
manager can use the shared secret key to verify 
the peer device's authenticity as well as to nego- 
tiate a link key for encryption. A typical session 
between two Bluetooth devices begins with the 
formation of a piconet, followed by the exchange 
of LMP messages first to authenticate and then to 
negotiate new encryption keys with the peer 
device. Only upon successful completion of the 
LMP handshake can further data exchange or 
voice communication take place. 

The level of security built into the version l.l 
specifications is satisfactory so long as the initial 
security associations are computed in a secure fash- 
ion. The baseband and LMP specifications also 
define a method, called pairing, for creating a new 
security association between two devices when they 
pair for the first time. The method uses an out-of- 
band channel for creating a security association, 
which is then used as a seed to compute a crypto- 
graphically secure shared secret key. By out-of-band 
channel I mean a user typing a randomly chosen 
PIN number on both devices. Clearly, the security of 
a pairing phase is limited by a user's ability to 
choose good PIN numbers. In scenarios when one 
device in the pair does not have a keypad, security 
can be fiirther compromised if the chosen PIN is 
transmitted to the other device in clear text. 

Putting the Pieces Together 

The ultimate objective of the Bluetooth specifica- 
tions is to allow multivendor applications to inter- 
operate. Different applications may run on differ- 
ent devices, and each device may use a protocol 
stack from one vendor and a Bluetooth chip from 
another. Yet interoperability among applications 
is achieved when different implementations com- 
ply with the same core and profiles specifications. 
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At the lowest layer, Bluetooth chips from dif- 
ferent vendors interoperate over the air link 
because all Bluetooth chips implement the base- 
band and LMP specifications. Bluetooth stacks, 
which can be implemented as either firmware or 
software, include the L2CAP, SDP, and RFCOMM 
layers. It is relatively easy to port a Bluetooth stack 
from one platform to another because the lowest 
layer of a Bluetooth stack interfaces with a Blue- 
tooth chip via a standard HCI interface which is 
also a part of the 1.1 specifications. 

Porting a Bluetooth application from one stack 
to another, however, is more difficult. The appli- 
cation can use any standard API to access IP, PPP, 
OBEX, or RFCOMM layers of the Bluetooth stack, 
but there is no standard API to access the control 
functions provided by the Bluetooth stack. For 
example, if an application were to initiate a Blue- 
tooth inquiry to discover other devices in its 
neighborhood, it must use an API specific to the 
stack vendor to access those functions. 

Support for RFCOMM has been provided only 
for backward compatibility reasons. Legacy 
applications that run over serial cable, such as 
OBEX and PPP, will work over any Bluetooth 
stack without modifications. Thus, synchroniza- 
tion and IP-based applications already developed 
by vendors can be made available immediately 
when PDAs, cell phones, and laptops are Blue- 
tooth enabled. The next release of Bluetooth 
specifications will provide better support for IP 
(without going through the PPP and RFCOMM 
layers), thus increasing portability of IP-based 
applications across all Bluetooth platforms. Stan- 
dardization of control APIs, however, remains an 
unfinished task that has not yet been taken up by 
any standards organization. 

Conclusion 

Whether Bluetooth will live up to its promise or 
not will depend on a number of factors, some of 
which involve market forces rather than technical 
issues. For example, unless the initial adoption of 
Bluetooth is high, it will be difficult to meet the 
low-cost objective. 

Security is also an open issue— as it is in almost 
all Internet applications. The free flow of informa- 
tion is desirable in some scenarios, but in general, 
proper safeguards are required to prevent the 
unauthorized leakage of information. The Blue- 
tooth SIG is addressing the security issues associ- 
ated with the inirial usage scenarios, but new 
applications of Bluetooth will require a closer look 
at potential security threats. 



One technical issue is that profile-based inter- 
operability is easy to manage when the number 
of profiles is small, but market predictions indi- 
cate that more than a billion devices will be 
equipped with Bluetooth chips by 2005. This 
number is significantly greater than the number 
of hosts connected to the Internet today. As peo- 
ple find innovative uses of this technology, new 
profiles will be needed. Ensuring compliance with 
a rapidly increasing number of profiles will like- 
ly be difficult to maintain in the future. A good 
solution to this problem would be to quickly 
standardize an IP-over-Bluetooth specification 
since interoperability at the IP layer would auto- 
matically translate into interoperability at the 
applications layer. Some efforts have already 
begun within the Bluetooth SIG as well as in the 
IETF to resolve this issue. 

Bluetooth has caught the attention of consumers 
because it would enable them do things that are 
otherwise cumbersome or not possible: synchro- 
nizing data between cell phones, laptops, and PDAs; 
using cell phones as cordless phones when at home; 
and connecting PDAs to the office LAN. The value 
proposition is therefore strong. The challenge is for 
vendors to meet these expectations. 
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1 Overview 



The Bluetooth protocol stack contains a service discovery protocol (SDP) [1] that 
enables the retrieval of information that can be used to configure the stack to 
support several end-user applications. SDP can further be used to locate 
services that are available on devices in the vicinity of the user. Having located 
available services, a user may then select to use any of them. 

SDP provides direct support for the following set of service inquires: 

• search for services by service class; 

• search for services by service attributes; and 

• service browsing. 

A service discovery profile is provided [2] that describes a generic syntax and 
semantics to be used by a service discovery application to locate services in 
other processes using Bluetooth SDP. The primitives are described in a generic 
way as these primitives may be operating environment dependent. 

The Salutation Architecture [3] provides a standard method for applications, 
services and devices to describe and to advertise their capabilities to other 
applications, services and devices and to find out their capabilities. The 
architecture also enables applications, services and devices to search other 
applications, services or devices for a particular capability, and to request and 
establish interoperable sessions with them to utilise their capabilities. 

This paper maps Bluetooth service discovery to the Salutation Architecture. 
Specifically this paper (1) maps the Bluetooth service discovery profile to the 
Salutation APIs and (2) maps the Bluetooth Service Discovery Protocol to the 
Salutation Manager. 
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2 Bluetooth Summary 



2.1 Bluetooth Service Discovery Protocol 

Figure 2.1 shows the Bluetooth protocols and supporting entities. 




service 
records DB 



LocDev 



RemDev 



Figure 2.1: The Bluetooth protocol for the sen/Ice discovery profile 



The blocks marked SDP indicate the service discovery component. An SDP block 
generates and receives Bluetooth service discovery protocol (SDP) commands 
and responses from the lower layers of the Bluetooth stack. 

SDP provides a means for client applications to discover the existence of 
services provided by server applications as well as the attributes of those 
services. The attributes of a service include the type or class of service offered 
and the mechanism or protocol information needed to utilise the service. 

As shown in Figure 2.1 , SDP involves communication between an SDP server 
located on RemDev and an SDP client located on LocDev. The server maintains 
a list of service records that describe the characteristics of services associated 
with the server. Each service record contains information about a single service. 
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A client may retrieve information from a service record maintained by the SDP 
server by issuing an SDP request. 

All of the information about a service is maintained by an SDP within a single 
service record. The service record consists entirely of a list of service 
attributes. Each service attribute describes a single characteristic of a service. 

SDP uses a request/response model where each transaction consists of one 
request protocol data unit (PDU) and one response PDU. Generally, each type 
of request PDU has a corresponding type of response PDU. However, if the 
server determines that a request is improperly formatted or for any reason the 
server cannot respond with the appropriate PDU type, it will respond with an 
SDP_ErrorResponse PDU. 

2.1.1 Protocol Data Unit Types 

• ServiceSearcli Transaction: 

The SDP client generates a SDP_ServiceSearchRequest to locate service 
records that match the service search pattern given as the first parameter of 
the PDU. Upon receipt of this request, the SDP server will examine its 
service record data base and return an SDP_ServiceSearchResponse 
containing the service record handles of service records that match the given 
service search pattern. 

• ServiceAttrlbute Transaction: 

The SDP client generates a SDP_ServiceAttributeRequest to retrieve 
specified attribute values from a specific service record. The service record 
handle of the desired service record and a list of desired attribute ids to be 
retrieved from that service record is supplied as parameters. 

• ServiceSearchAttribute Transaction: 

The SDP_ServiceSea.rchAttributeRequest transaction combines the 
capabilities of the SDP_ServiceSearchRequest and the 
SDP_ServiceAttributeRequest into a single request. As parameters, it 
contains both a service search pattern and a list of attributes to be retrieved 
from service records that match the service search pattern. The 
SDP_ServiceSearchAttributeRequest and its response are more complex and 
may require more bytes than separate SDP_ServiceSearch and 
SDP_ServiceAttribute transactions. However, using 
SDP_ServiceSearchAttributeRequest may reduce the total number of SDP 
transactions, particulariy when retrieving multiple service records. 

• Brov\fslng for Services: 

Normally, a client searches for services based on some desired 
characteristic(s) of the services. However, there are times when it is desirable 
to discover which types of services are described by an SDP server*s service 
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records without any a priori information about the services. This process of 
looking for any offered services is termed browsing. In SDP, the mechanism 
for browsing for services is based on an attribute shared by all service 
classes. This attribute is called the BrowseGroupList attribute. Each attribute 
represents a browse group with which a service may be associated for the 
purpose of browsing. When a client desires to browse an SDP server's 
services, it creates a service search pattern containing the attribute that 
represents the root browse group. 

Refer to Reference [1] for details about the Bluetooth service attribute definitions. 

2.2 Bluetooth Profile Stack 

Refering to Figure 2.1, the service discovery user application (SrvDscApp) in a 
local device (LocDev) interfaces with the SDP protocol to send service inquires 
and receive service inquire responses from other remote devices (RemDev). The 
SDP uses the connection-oriented (CO) transport service in L2CAP, which in turn 
uses the baseband asynchronous connectionless (ACL) links to carry ultimately 
the SDP PDUs over the air. 

2.3 Bluetooth Service Primitives 

This section briefly describes the service primitives that the Bluetooth stack 
needs to expose to the SrvDscApp to perform its task. 

Table 2.1 contains a minimum set of enabling service primitives to support a 
SrvDscApp. Different implementations of the Bluetooth stack shall (at a minimum) 
enable the functions that these service primitives provide. For example, the 
serviceSearchO service primitive permits multiple identical operations to be 
handled at once. A stack implementation that requires an application to 
accomplish this function by iterating through the multiple identical operations one 
at a time will be considering as enabling the function of this service primitive. 



service primitive 


function accomplished 


serviceBrowse 

( 

LIST(RemDe\/;; 
LIST( RemDevRelation ); 
LIST( browseGroup ); 
stopRule 

) 


searches for services (service browsing) tliat belong to 
tlie list of browseGroup services in the devices in the list 
of RemDevs; the search may be further qualified with a 
list of RemDevRelation parameters, whereby a user 
specifies the trust and connection relation of the devices 
to be searched, e.g., search only the devices that are in 
the RemDev list for which pairing has been performed; 
search continues until the stopping rule stopRule is 
satisfied 


serviceSearch 

( 

L\SJ{ RemDev)] 

LIST( RemDevRelation ); 

LIST( searchPath, 


searches whether the devices listed in the list of 
RemDevs support services in the requested list of 
services; each service in the list must have a service 
search path that is a superset of the searchPath\ for 
each such service the values of the attributes contained 
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stthbutoList ); 
stopRule 

) 


in tne corresponaing aunDuieusi are aiso rexnevea, ine 
search may be further qualified with a list of 
RemDevRelation parameters, whereby a user specifies 
the trust and connection relation of the devices to be 
searched, e.g., search only the devices that are in the 
RemDev list for which pairing has been performed; 
search continues until the stopping rule stopRule is 
satisfied 


enumerateRemDev 

LIST( classOfDevice ); 
StopRule 


searches for RemDev in the vicinity of a LocDev; 
RemDev searches may optionally be filtered using the 
list of ClassOfDevice, e.g., LAN APs; search continues 
until the stopping rule stopRule is satisfied 


getRemDevName 

LIST( phmitiveHandle ); 
StopRule 


retrieves the names of devices associated with the 
execution of the service primitives identified by the list of 
phmitiveHandle;^ search continues until the stopping 
rule stopRule is satisfied 


terminatePrimitive 

phmitiveHandle] 
retumResults 


terminates the actions executed as a result of invoking 
the services primitive identified by the phmitiveHandle] 
optionally, this service primitive may return any partially 
accumulated results related to the terminated service 
primitive 



Table 2. 1: Service primitives in support of SrvDscApp 



^ It is assumed that each invocation of a service primitive can be identified by a phmitiveHandle 
the realization of which is implementation dependent. 
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3 Salutation Architecture Summary 



The Salutation Architecture was created to solve the problems of service 
discovery and utilization among a broad set of appliances and equipment and 
in an environment of widespread connectivity and mobility. 

The architecture provides a standard method for applications, services and 
devices to describe and to advertise their capabilities to other applications, 
services and devices and to find out their capabilities. The architecture also 
enables applications, services and devices to search other applications, services 
or devices for a particular capability, and to request and establish interoperable 
sessions with them to utilize their capabilities. 

Given the diverse nature of target appliances and equipment in an environment 
of widespread connectivity, the architecture is processor, operating system, and 
communication protocol independent, and allows for scalable implementations, 
even in very low-price devices. 

As shown in Figure 3-1, the Salutation Architecture defines an entity called the 
Salutation Manager (SLM) that functions as a service broker for applications, 
services and devices called a Networked Entity. The Salutation Manager allows 
Networked Entities to discover and utilize the capabilities of other Networked 
Entities. 



Service 



Client Client Service 



SLM 




Salutation Manager 


Salutation 
Manager 
Protocol 


TM 


TM : TM 


Xport 


Transport 


Transport 



SLM-API 



Client 
SLM 

tm" 

Xport 



Figure 3-1: Model of the Salutation Manager 



A Networked Entity may be a service provider, called a Service. The Service 
registers its capability with a Salutation Manager. A Networked Entity may be a 
service user, called a Client. The Client discovers Services and requests to use 
them through a Salutation Manager. A Networked Entity may serve as either a 
Client or a Service, or both. 
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The Salutation Manager provides a transport-independent interface, called the 
Salutation Manager Application Program Interface (SLM-API), to Services 
and Clients. The architecture defines an abstract procedural SLM-API. 

The Salutation Manager communicates with other Salutation Managers to 
perform its role as a service broker. The Salutation Manager-to-Salutation 
Manager communications protocol is defined by the Salutation Architecture and 
called the Salutation Manager Protocol. The Salutation Manager binds to a 
specific transport through a Transport Manager (TM) unique to that transport 
class. 

3.1 Service Broker Tasks 

To perform its function as service broker, the Salutation Manager provides four 
basic tasks: 

• Service Registry 

• Service Discovery 

• Service Availability 

• Service Session Management 

Service Registry and Service Discovery, and the APIs which expose these 
functions to the Client/Server layer, are of primary interest for this document. 

3.1.1 Service Registry 

The Salutation Manager contains a Registry to hold information about Services^. 
The minimum requirement for the Registry is to store information about Services 
connected to the Salutation Manager Optionally, the Salutation Manager 
Registry may store information about Sen/ices that are registered in other 
Salutation Managers. All requests by other equipment for Salutation resources 
would be directed toward other Salutation Managers which would respond 
accordingly. 

The limit on Registry implementation is the size of the storage reserved for the 
Registry function. 

3.1.2 Service Discovery 

The Salutation Manager can discover other remote Salutation Managers and 
determine the Services registered there. Service Discovery is performed by 
comparing a required Services type(s), as specified by the local Salutation 
Manager, with the Service type(s) available on a remote Salutation Manager. 
Through manipulation of the specification of required Service type(s), the 
Salutation Manager can determine: 

• The characteristics of all the Services registered at a remote Salutation 
Manager 



^ Equivalent to Bluetooth service record DB shown in Figure 2.1 
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• The characteristics of a specific Service registered at a remote Salutation 
Manager 

• The presence of a Service on a remote Salutation Manager matching a 
specific set of characteristics. 

3.2 Salutation Manager API Specification 

This section describes an abstract definition of the SLM-API, the application 
programming interface provided by the Salutation Manager to Salutation 
applications. More specifically, this section focuses on the Salutation Service 
Registration and Service Discovery APIs. It is intended to provide a level of 
understanding to aid in the mapping of Salutation APIs to Bluetooth SDP 
functions. The SLM-API supporting the mapping are: 

• Service Registration 

sImRegisterCapabilityO 
Sim UnregisterCapabilityO 

• Service Discovery 

sImSearchCapabilityO 
sIm QueryCapabilityO 
3.2.1 Salutation Manager API Description 

The SLM-APIs are described in the abstract in this section. 

When the Client calls the Salutation Manager through the SLM-API, it is called 
the local Salutation Manager. Any other Salutation Manager is called a remote 
Salutation Manager Refer to Reference [3] for details of the API attributes of 
SLM-ID, Functional Unit Description Record, and Service Description Record. 



Abstract SLM-API 


function accomplished 


SImRegisterCapabilityO 
Input Parameters 

( 

Functional Unit Description 
Record^; 

Callback Entry for Open Service 
Indication; 

Callback Entry for Close Sen/ice 


The SImRegisterCapabilityO function is called by 
Services to register their specific instances of Functional 
Units with the local Salutation Manager. The specific 
instance Is described in a record called a Functional 
Unit Description Record. The calling Service passes a 
Functional Unit Description Record, which describes its 
capability, to the Salutation Manager. The Salutation 
Manager returns a Functional Unit Handle that uniquely 
identifies the Functional Unit among all the Functional 
Units registered with the Salutation Manager, 



^ The Salutation Architecture defines the Functional Unit Description Record as a record that 
identifies the Functional Unit, and the capabilities of that instance of the Functional Unit. The 
Functional Unit maps to the Bluetooth Service and capabilities map to the Bluetooth Attributes 
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Indication; 

Callback Entry for Receive Data 
Indication; 

Preferred Functional Unit 
Handle 

) 

Output Parameter 

( 

Functional Unit Handle 

) 


While a Service has a Functional Unit registered with a 
local Salutation Manager, the Functional Unit's 
capability may be included in the response to a Query 
Capability request. 

The Callback Entries are provided to provide an entry 
point into a Service when that service is to be used. 
Entry points are provided for opening and closing the 
Service as well as for receiving data. 

The Service may attempt to specify a handle for the 
functional unit instance being registered. This value will 
be assigned if it is not currently in use. Othenwise, the 
Salutation manager will assign a random, unused value 
for the handle. 


slmUnregisterCapabilityO 

Input Parameters 

( 

Functional Unit Handle 

) 

Output Parameter 

None 


The Service, which has registered itself with the local 
Salutation Manager by calling the 
sImRegisterCapabilityO function, calls this function to 
unregister itself from the local Salutation Manager. 

The Functional Unit Handle is the value returned by the 
SImRegisterCapabilityO used to register this Service. 


sImSearchCapabilityO 

Input Parameters 

( 

SLM-ID; 

Service Description Record'^; 
Output Parameter 

( 

Listof SLM-IDs 

) 


The Client calls this function to ask the local Salutation 
Manager to search for Salutation Managers having a 
registered Functional Unit with a specific capability. The 
local Salutation Manager returns the list of SLM-IDs to 
the Client. Salutation Manager(s) whose SLM-ID(s) are 
included in the list has(have) a Functional Unit(s) that 
can provide the Service requested by the Client. 

SLM-ID is NULL for version 2.0 of the Salutation 
Arrhitpcture 

Service Description Record describes the Service(s) 
and their capabilities that are of interest to the Client. A 
Service Description Record that contains a Functional 
Unit Description Record of "All Cair Functional Unit ID 
with no Attribute Records, may be specified to get the 
list of all the SLM-IDs of Salutation Managers known to 
the local Salutation Manager. 


sIm QueryCapabilityO 
Input Parameters 

( 

SLM-ID; 

Service Description Record 

) 


The Client calls this function to discover registered 
Functional Units and their capabilities at a specific 
Salutation Manager. 

SLM-ID specifies the target Salutation Manager. If 
NULL is specified, the target Salutation Manager is the 
local Salutation Manager. 

The Input Service Description Record describes the 
Service(s) and their capabilities that are of interest to 



^ The Salutation Architecture defines the Service Description Record as a collection of one or 
more Functional Unit Description Records. The Sen/ice Description Record describes all the 
services sought by a Client or all the services maintained by a Service. 
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Output Parameter 


the Client. 


Service Description Record 


The Output Service Description Record describes the 
Service(s) and their capabilities that match the Input 


) 


Service Description Record. 



3-3 Service Discovery Flow 

The flow of Remote Service Discovery messages and calls are depicted in Table 
3-4. Salutation APIs are used by the Client and Functional Unit to access their 
respective Salutation Managers. Salutation Protocol flows between the Client- 



Client 


Client-side 
Salutation Manager 


Salutation 
Protocol 


Service-side 
Salutation Manager 


Functional Unit 








<== sImRegisterCapabilityO call 
sImRegisterCapabilityO return ==> 


sImSearchCapabilityO call ==> 










Query Capability call ==> 
<== Query Capability reply 

(This step is repeated for each known SLM. The reply data maybe 
cached for the next step.) 




<== SImSearchCapabilityO return 








sImQueryCapabilityO call ==> 










Query Capability call ==> 
<== Query Capability reply 

(This step is optional, depending on the caching capability of the 
Client's Salutation Manager.) 




<== SImQueryCapabilityO return 

(This step is repeated for each 
Salutation Manager found by the 
Search Capability. 
The Salutation Manager retums the 
cached data.) 














<== sImUnRegisterCapabilityO call 
slmUnRegisterCapabilityO return ==> 



Table 3-4: Remote Service Discovery Flow Diagram 
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4 Mapping Bluetooth SDP to Salutation APIs 

Two approaches will be used for mapping Bluetooth SDP primitives to Salutation 
APIs. 

The first approach will assume that the Salutation APIs are implemented on top 
of the Bluetooth service discovery. In this case, the mapping will show how SDP 
attributes can be passed in the Salutation APIs. That is: 

Salutation APIs ^ Bluetooth SDP ^ Bluetooth Protocol 

Here, the Salutation APIs are implemented as the entry to Bluetooth SDP. SDP 
extracts the information it requires from the APIs and processes according to the 
mapping to SDP primitives. 

The second approach will assume that Salutation Manager can be map directly to 
the SDP protocol using a Bluetooth specific Transport Manager (indicated by TM 
in Figure 3.1). That is: 

Salutation APIs Salutation Manager -> Bluetooth Protocol 

Here, SDP is replaced by the Salutation Manager, with the Salutation Manager 
mapping its functionality to SDP protocol. 

4.1 General Mapping Assumptions 

• SDP is a service manager. For RemDev, it provides the ability to 
specify local services and respond to requests to discover the services 
it manages. For LocDev, it provides the ability for SvcDscApp to ask 
RemDev if it supports specific services. The APIs provide a means for 
application developers to access the functions of the SDP service 
manager. 

• Service requests by LocDev are accessed through Salutation 
sImSearchCapabilityO and sIm QueryCapabilityQ API calls. 

• Certain Bluetooth RemDevs will have the need to dynamically update 
the services they support. That is, a RemDev may need to update the 
service records maintained in the service record DB. Salutation 
slmRegisterCapabilityO and slmilnreglsterCapabUityO API calls will 
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be mapped on the RemDev side to support dynamic registry of 
services. 

4.2Salutation API Mapping 

This section describes how Salutation APIs can be used to represent the SDP 
primitives. 

4.2.1 Configuration 

The configuration used for this mapping is shown in Figure 4.1. The figure shows 
the use of the Salutation APIs as the entry point to SDP. No other changes have 
been made to the Bluetooth model shown in Figure 2.1. 




service 
records DB 



LocDev 



RemDev 



Figure 4.1: Salutation API Mapping to Bluetootli SDP 



4.2.2Mapping 

Table 4.1 depicts the general mapping of SDP primitives to Salutation APIs. 
Although there are no parallels defined in the SDP primitives, the Salutation 
Register Capability and Unregister Capability APIs are included for 
completeness. 
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The function provided by the SDP getRemDevName - the return of the names of 
devices identified by the SDP service searches - is an integral part of the 
Salutation's slmSearchCapabilityQ and slmQueryCapability() calls. As a result, 
one Salutation API can provide the function of two SDP prinnitives. 

This mapping uses the functional definition of the Salutation APIs, but not the 
parameter values. The APIs becomes a vehicle for passing the SDP parameters 
to the Bluetooth SDP Manager. That is, the SLM-ID and Service Description 
Records parameters of the Salutation APIs are replaced with the appropriate 
SDP parameter values. Therefore, the parameters defined by the SDP primitives 
are passed without modification to the Bluetooth SDP Manager via the Salutation 
API format. The parameter returned from the search operations is a list of the 
names of the devices identified by the search. 







ServiceBrowse, getRemDevName 


SImQueryCapabilityO 

Input Parameters 

( 

USl{RemDev)\ 
LIST( RemDevRelation ); 
LIST( browseGroup ); 
stopRule 

) 

Output Parameter 

( 

List of Device Names 

) 


ServiceSearch, getRemDevName 


SImQueryCapabilityO 

Input Parameters 

( 

LIST(RemDev;; 

LIST( RemDevRelation ); 

L!ST( searchPath, 

attributeList ); 
StopRule 

) 

Output Parameter 

( 

List of Device Names 

) 


EnumerateRemDev, getRemDevName 


SlmSearchCapabllityO 

Input Parameters 

( 

LIST( classOfDevice ); 
StopRule 
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) 

Output Parameter 

( 

List of Device Names 

) 


(No SDP Registration Primitives) 


SImRegisterCapabilityO 

Input Parameters 

( 

L\ST{attributeList)\ 

Callback Entry for Open 
Service Indication; 

Callback Entry for Close 
Service Indication; 

Callback Entry for Receive 
Data Indication; 

Preferred Functional Unit 
Handle 

) 

Output Parameter 

( 

Functional Unit Handle 

) 


^No SDP Reaistratlon Primitives) 


sImUnregisterCapabilityO 

Input Parameters 

( 

Functional Unit Handle 

) 

Output Parameter 

None 



Table 4.1 SDP primitive to Salutation APi mapping 



The sImSearchCapabilityO call is used for both the serviceBrowse and the 
serviceSearch SDP primitives. The differentiater is the presence or absence of 
the browseGroup list parameter. If this parameter is present, the Bluetooth SDP 
Manager performs a browse operation. OthenA^ise a search operation is 
performed. 

The Functional Unit Description Record parameter of the Salutation 
sImRegisterCapabilities API is replaced with the SDP attributeUst parameter that 
specifies the capabilities of the service being registered. The callback parameters 
remain in the API definition, providing a means to define the entry points for 
service utilization. The returned value remains a handle of the registered service. 
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This value is used in the slmUnregiserCapability API to identify the service to be 
removed from public access. 

4.2.3Sumnfiary 

The Salutation API mapping provides a means to pass SDP primitive attributes to 
the Bluetooth SDP Manager. 

4.3Salutation Manager Mapping 

This section describes how the Salutation Manager, accessed via the Salutation 
APIs, can be used to generate Bluetooth SDP protocol. 




LocDev 



RemDev 



Figure 4.2: Salutation Manager Mapping to Bluetooth SDPpmtocol 
4.3.1Configuration 

The configuration used for this mapping is shown in Figure 4.2. The figure shows 
the use of the Salutation Manager (SLM) in both LocDev and RemDev to provide 
the service the management functionality of SDP. SLM exposes the existing 
Salutation APIs to the SrvDscApp and the RemSrvApp. SLM generates the 
appropriate SDP protocol through its TM, handing it off to L2CA layer. SLM also 
responds to SDP protocol received from L2CA. No other changes have been 
made to the Bluetooth model shown in Figure 2-1. 
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4.3.2Mapping 

Table 4.2 depicts the general mapping of Salutation Manager functions to the 
SDP protocol. LocDev and RemDev use the Salutation APIs to access their 
respective Salutation Managers. Bluetooth Service Discovery Protocol flows 
between the LocDev and RemDev Salutation Managers. 

Two transformations exist between the Salutation API layer and the Bluetooth 
SDP protocol layer. The Salutation Manager provides these transformations. 

sImSearchCapabilityO <—> SDP_ServiceSearch 

sImQueryCapabilityO SDP_ServiceSearch & SDP_ServiceAttribute 

4.3.2,1 Capability Search 

The Salutation slmSearchCapabilityQ API call is mapped by the Salutation 
Manager's TM to a Bluetooth ServiceSearch protocol. The Salutation Manager 
maps the Functional Unit Description Record passed in the API to a 
ServiceSearchPattern attribute. The Salutation Manager then makes an L2CAP 
connection with a Bluetooth RemDev and sends the Service SearchPattern to the 
RemDev in a SDP_SereviceSearchRequest. Note that the ServiceSearchPattern 
may contain BrowseGroupList attributes as deemed necessary by the transform 
process. 

If the RemDev Salutation Manager can match existing registered services with 
the ServiceSearchPattern, a SDP_ServiceSearchResponse is sent back to the 
LocDev Salutation Manager containing a list of service record handles for service 
records that match the ServiceSearchPattern in the request. 

This process is repeated by establishing an L2CAP connection with another 
RemDev in radio range of LocDev. When all RemDevs have been contacted in 
this fashion, the LocDev Salutation Manager builds a list of device IDs returning 
positive responses and returns them to the calling application as a list of SLM- 
IDs. The Salutation Manager maintains a list of SLM-IDs and corresponding 
RemDev addresses for future SDP activity. 

Specific transformations from Functional Unit Description Records to a 
ServiceSearchPattern will depend on the definition of ServiceSearchPattern for 
Bluetooth. For example: 
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LocDev 


Client-side 
Salutation Manager 


Bluetooth Service 
Discovery 
Protocol 


Service-side 
Salutation Manager 


RemDev 








<== sImRegisterCapabilityO call 
sImRegisterCapabilityO return ==> 


SlmSearchCapabilityO call ==> 










SDP_ServiceSearchRequest ==> 
<== SDP_ServiceSearchResponse 






(This step is repeated for each known Bluetooth device. The reply data 
maybe cached for the next step.) 




<== SlmSearchCapabilityO return 








SImQueryCapabilityO call ==> 










SDP_ServiceSearchRequest ==> 
<== SDP_ServiceSearchResponse 






SDP_ServiceSearchAttributeRequest ==> 






<== SDP_ServiceSearchAttributeResponse 






(This step is repeated for each service record handle identified in the 
previous SDP_ServiceSearchRequest.) 




<== SImQueryCapabilityO return 














<== sImUnRegisterCapabilityO call 
sImUnRegisterCapabilityO return ==> 



Table 4-2: Remote Service Discovery Flow Diagram 



if the following Service Classes are defined: 

DuplexColorPostscriptPrinterServiceClass, 
ColorPostscriptPrinterServiceClass, 
PostscriptPrinterServiceClass, 
PrinterServiceClass, 

and the slmSerchCapabilityO call includes a [Print] Functional Unit 
Description Record with attributes of Postscript .Duplex, and Colate, 

then the resulting ServiceSearchPattern would contain attributes for 
PrinterServiceClass and PostscriptPrinterServiceClass. 
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The TM of the Salutation Manager on RevDev makes a reverse transformation 
from ServiceSearchPattern and compares to the registered Functional Unit 
attributes. 

4,3.2.2 Capability Query 

The Salutation sImQueryCapabilityO API call is mapped by the Salutation 
Manager to a Bluetooth ServiceSearch and ServiceAttribute protocols in a two 
step process. 

1 . The LocDev Salutation Manager's TM maps the Service Description Record 
passed in the API to a ServiceSearchPattern attribute. The Salutation 
Manager then makes an L2CAP connection with the Bluetooth RemDev 
represented by the SLM-ID passed in the API call, and sends the 
ServiceSearchPattern to the RemDev in a SDP_SereviceSearchRequest. 
Note that the ServiceSearchPattern may contain BrowseGroupList attributes 
as deemed necessary by the transform process. 

If the RemDev Salutation Manager can match existing registered services 
with the ServiceSearchPattern, a SDP_ServiceSearchResponse is sent back 
to the LocDev Salutation Manager containing a list of service record handles 
for service records that match the ServiceSeachrPattern in the request. 

2. To determining attribute specifics, the LocDev Salutation Manager selects one 
of the service record handles returned in Step 1. The Salutation Manager's 
TM maps the Service Description Record passed in the API to an 
Attribute! DList attribute. The Salutation Manager then sends the service 
record handle and the AttributelDList to the RemDev in a 
SDP_ServiceAttributeRequest. 

The RemDev returns a SDP_ServiceAttributeResponse containing an 
AttributeList identifying a list of attributes and their values for the requested 
service record. 

Step 2 is repeated for each service record handle returned in Step 1. 

When this cycle is completed, the LocDev Salutation Manager assembles a 
Service Description Record from the values returned by in the 
SDP_ServiceAttributeResponses. This Service Description Record is return to 
the calling application. 

As before, specific transformations from the Functional Unit Description Records 
(contained in the Service Description Record) to a ServiceSearchPattern will 
depend on the definition of ServiceSearchPattern for Bluetooth. The same 
applies to transformations from Functional Unit Description Records to 
AttributlDList. For example: 
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if the following Service Classes are defined: 

DuplexColorPostscriptPrinterServiceClass, 
ColorPostscriptPrinterServiceClass, 
PostscriptPrinterServiceClass, 
PrinterServiceClass, 

and the slmQueryCapabilityQ call includes a [Print] Functional Unit 
Description Record with attributes of Postscript, Duplex, and Collate 

then the resulting ServiceSearch Pattern would contain attributes for 
PrinterServiceClass and PostscriptPrinterServiceClass, and the 
AttributelDList would contain attribute IDs for Postscript, Duplex and Collate. 



4.3.3 Stop Rules 

Instances of the Salutation Manager, such as IBM's Salutation Manager Toolkit, 
provide a control interface outside of the Salutation APIs. This mapping assumes 
that such a control interface exists for the Salutation Manager supporting 
Bluetooth. The Bluetooth stop rules will be set via this interface. 

4.3.4 Summary 

The Salutation Manager mapping provides a means to use the Salutation 
Manager as a service broker in the Bluetooth environment. Because Salutation 
Manager is independent of underlying protocols and operating environments, a 
Salutation implementation can be a single application interface to numerous 
protocols. For example, in additions to the Bluetooth mapping. Salutation has 
been specified for TCP/IP and IR. A mapping to SLP is also being described. 

As an example, Figure 4.3 shows a single service discovery application using the 
Salutation APIs to access the Salutation Manager to locate service in both the 
Bluetooth and TCP/IP environments. The advantage of this technique is to 
present a single methodology and API set to application for service discovery. 
The application need not know where a service resides, and therefore what 
service discovery primitives to uses, prior to performing a service search. 
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S rvDcsApp 



S a lutation Manager 



TM 



TM 



SLM-API 



TCP/IP Bluetooth 




Figure 4.3: Salutation Manager In mixed transport environment 
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6 Definitions 



Term 


Definition 


Functional Unit 

Description 

Record 


The Salutation Architecture defines the Functional Unit Description 
Record as a record that identifies the Functional Unit, and the 
capabilities of that instance of the Functional Unit. The Functional 
Unit maps to the Bluetooth Service and capabilities map to the 
Bluetooth Attributes. 


Callback Entry for 
Open Sen/ice 
Indication 


The specified entry of the calling Client is called back by the 
Salutation Manager when an Open Service request for the Functional 
Unit is received. 


Callback Entry for 
Close Service 
Indication 


The specified entry of the calling Client is called back by the 
Salutation Manager when a Close Sen/ice request for the Functional 
Unit is received. 


Callback Entry for 
Receive Data 
Indication 


The specified entry of the calling Client is called back by the 
Salutation Manager when a Transfer Data request for the Functional 
Unit is received. 


Preferred 
Functional Unit 
Handle 


If the calling Client wants to be assigned any specific value as its 
Functional Unit Handle, the preferred value is specified in this 
parameter. Otherwise, zero (0) should be specified. 


Functional Unit 
Handle 


The Salutation Manager generates a unique Functional Unit Handle 
value and returns it to the calling Client. If the function fails, zero (0) 
is returned. 


SLM-ID 


This parameter shall be NULL, indicating the local Salutation 
Manager, under version 2.0 of the Salutation Architecture. 


Service 

Description 

Record 


The Salutation Architecture defines a Service Description Record as 
a collection of one or more Functional Unit Description Records. The 
Service Description Record describes all the services sought by a 
Client or all the services maintained by a Service. 
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1.0 Introduction 

Several attacks on IEEE 802.1 1b have been described in the media [1]. It has 
been shown that the WEP security framework used in IEEE 802.1 1 is susceptible 
to both attacks on data content and user authentication. These exposures allow 
an attacker to both inappropriately intercept data and also gain access to a 
network by impersonating a valid user. 

Bluetooth and IEEE 802.1 lb are different, complementary technologies [10]. 
IEEE 802.1 lb is largely applied to LAN access, while Bluetooth LAN access is 
only one of many applications, most of which focus on smaller personal area 
networks (PANs). Different target applications and technology dictate different 
security architectures. With the differences between Bluetooth technology and 
IEEE 802.1 lb in mind, one may question the validity of comparing the security 
architectures of the two technologies. We feel, however, that such a comparison 
is valid. Indeed, from a user perspective the two technologies are really quite 
similar. Both are methods which allow computers to communicate to other 
devices, both use wireless technology, both operate in the 2.4 GHz spread 
spectrum band, etc. Due to these similarities, the public sometimes confuses 
Bluetooth communications with IEEE 802.1 lb. In addition, 802.1 lb security 
concerns have been unjustifiably applied to Bluetooth communications. 
However, these attacks do not apply to Bluetooth technology. 

Here we discuss the two main attacks on 802.1 1b that have been described in 
the literature. We also explain why these attacks are not effective with Bluetooth 
wireless communications. 



2.0 802.11b Eavesdropping 

When a user sends data over a wireless network, he has a reasonable 
expectation that such data is not easily readable by unauthorized persons. 
Unlike a wired network, which requires a physical intrusion, wireless data packets 
can be received by anyone nearby with an appropriate receiver, potentially 
outside of the physical security barriers of an organization. This allows, so called 



parking lot attacks, in which an attacker sits in a car in the parking lot of the 
intended victim. Accordingly, both Bluetooth and 802.11 technologies utilize data 
encryption in lower network layers. 

The 802.1 lb specification utilizes a security framework called wireless equivalent 
privacy (WEP) protocol. A key component of WEP is the use of the stream 
cipher RC4. RC4 is a well-known and commonly used stream cipher, but its use 
in 802.1 1 b is questionable owing to the nature of a wireless packet networi<. 

RC4 operates by XORing the plaintext data with an encryption key stream. The 
result is commonly called ciphertext. RC4 is initialized with a secret WEP key 
and a public 24 bit long IV (initialization vector). If an attacker knows a plaintext 
and ciphertext pair a-priori, he can compute the encryption key stream using the 
XOR operation. Due to the low entropy of most plaintext messages, if an 
attacker can record a large number of ciphertext messages he can also compute 
the encryption key stream. For this reason users of RC4 are encouraged to 
change the encryption key on every message. The basic problem with RC4 
over 802. 1 1 b is that wireless channels, will, by nature, occasionally lose data or 
drop packets. Thus, the synchronization between the encryptor and decryptor is 
difficult to maintain for any length of time. To overcome this limitation, WEP 
maintains synchronization by changing the 24-bit initialization vector (IV) on each 
packet. However 802.1 1 b packets are relatively short. Therefore, one can 
expect a key/IV combination to be repeated every few seconds. Therefore one 
can expect a key/IV combination to be repeated relatively 
frequently. For more details, see Walker [2], and Borisov et a! [3]. 

Furthermore, there are more sophisticated attacks that exploit subtle properties 
of the key-scheduling algorithm of RC4 deployed with WEP. In July 2001 , 
Fluhrer, Mantin, and Shamir [4] showed how to exploit the particular way that 
802.1 lb derives the encryption key stream from the initialization vector IV and 
the shared key to completely recover the secret key. The paper shows how to 
recover the key, byte by byte, by exploiting a bias in the statistical distribution of 
the candidate secret keys that becomes manifest when observing the first byte of 
the key stream. By feeding the system with sufficiently many publicly known IV 
strings, the authors show how this bias can be exploited to correctly determine 
the key, one byte at a time. A team of AT&T researchers [2] soon after 
demonstrated a practical implementation of the attack using off-the-shelf 
equipment. The implementation showed that the key could be recovered by 
eavesdroppinging roughly 5 million encrypted packets. Thus WEP encryption is 
relatively easy to break. 



3.0 802. 11b False Authentication 

To gain access to a network, a user must be authenticated. While authentication 
is typically done at a higher network level, 802.1 lb and Bluetooth technologies 
also support device authentication. 



In 802.11b authentication is performed by a challenge response procedure using 
a shared secret. After requesting authentication, the authenticator sends the 
initiator a 128-octet random number challenge. The initiator encrypts the 
challenge using the shared secret and transmits it back to the authenticator. 
Encryption is performed by XORing the challenge with a pseudo-random string 
formed by the shared secret and a public IV. Note that the only thing that 
changes from authentication to authentication with a specific user is the plaintext 
message. 

A simple and powerful attack on this authentication mechanism is presented by 
Arbaugh, et. al [5]. First the intruder determines the pseudorandom string by 
recording the challenge (plaintext) and the response (ciphertext) and XORing 
them. He then impersonates the victim by using the pseudorandom string to 
compute the response to subsequent challenges. Notice that the attacker never 
needs to determine the shared secret; knowledge of the pseudorandom string is 
sufficient. 

4.0 Device Authentication in Bluetooth Technology 

Like 802.1 lb, Bluetooth technology provides a method for authenticating 
devices. Device authentication is provided using a shared secret between the 
two devices. The common shared secret is called a link key. This link key is 
established in a special communications session called pairing. All paired 
devices (devices that have had a previous connection to establish security 
procedures) share a common link key. There are two types of link keys defined in 
the [9]: unit keys and combination keys. 

A device using a unit key uses the same secret for all of its connections. Unit 
keys are appropriate for devices with limited memory or a limited user interface. 
During the pairing procedure the unit key is transferred (encrypted) to the other 
unit. Note that only one of the two paired units is allowed to use a unit key. 

Combination keys are link keys that are unique to a particular pa/r of devices. 
The combination key is only used to protect the communication between these 
two devices. 

Clearly a device that uses a unit key is not as secure as a device that uses a 
combination key. Since the unit key is common to all devices with which the 
device has been paired, all such devices have knowledge of the unit key. 



' 802,1 1 also supports "Open System Authentication" which is essentially no authentication, in other 
words, everyone who requests an authentication is authenticated. In our view, this is not a security flaw. 
The implementation choice to not authenticate is a valid one in some situations, such as where security 
requirements are limited or authentication is provided at a higher network level. A similar choice is 
allowed in the Bluetooth wireless communications. 



Consequently they are able to eavesdrop on any traffic based on this key. In 
addition, they could, in theory, be modified to impersonate other devices using 
the key. Thus, when using a unit key there is no protection against attacks from 
other devices with which the device has been paired. As a result, the Bluetooth 
SIG discourages the use of unit keys in secure applications. 

Authentication is performed with a challenge response scheme utilizing the E1 
algorithm. E1 is a modification of the block cipher SAFER+. The scheme 
operates as follows: The verifier issues a 128 bit long challenge. The claimant 
then applies E1 using the challenge, its 48-bit Bluetooth address, and the current 
link key. He then returns the 32 most significant bits of the128 bit result^. The 
verifier confirms the response, in which case the authentication has succeeded. 
In this case, the roles are switched and the same procedure is applied again, 
thereby accomplishing mutual authentication. 

The Bluetooth challenge response algorithm differs from that used in 
802.1 1 b in very important ways. In 802.1 1 b the challenge and response 
form a plaintext/ciphertext pair. This fact, combined with the simplicity of 
the encryption method (XOR), allow an Intruder to easily determine the 
authentication key string by listening to one authentication procedure. In 
contrast, the Bluetooth authentication method never transmits the ^ 
complete challenge response pair. In addition, the El algorithm is not 
easily invertible. Thus even if an attacker has recorded an authentication 
challenge response session, he cannot (directly) use this data to compute 
the authentication key. 

5-0 Data Eavesdropping, 802.11 

The Bluetooth standard does not use RC4 but rather the stream cipher EO, which 
is specifically designed to run over a Bluetooth wireless packet network. A 
unique encryption key is generated for each session, from which per-packet keys 
are derived, in a manner that avoids the problem in 802.1 lb caused by frequent 
reuse of per-packet keys. 

Direct attacks on the EO cipher are known but are of significant complexity. 
Jakobsson and Wetzel present two such attacks [6] the first is of 2''^° complexity, 
the second is a "birthday-type attack" of 2^®overall complexity. Fluher and Lukas 
[7] present an attack using observed keystream and the public knowledge of the 
encrypfion mechanism used in EO to compute the encryption key. Their method 
requires from 0(2^^) to 0(2^), depending on how much cleartext is available for 
the algorithm. They contend that the upper limit of EO is actually about 80 bits 
and question the extension of the EO key size to 128 bits as suggested in the 
Bluetooth specification [8]. As discussed by Jakobsson and Wetzel [6], attacks 
with a high order of complexity are not of practical value, but may point the way 



^ The remaining bits are called the Authentication Ciphering Offset (ACO) and are used to derive the 
ciphering key for data encryption. 



to a more efficient attack. As yet, a more efficient direct attack on EO has not 
been reported. 

Like RC4, EO required a ciphering key. The ciphering key is computed as a hash 
of a random number, the link key and a byproduct of the authentication 
procedure the Authentication Ciphering Offset (AGO). 

While the link key is also used to generate a ciphering key used for data 
encryption, it is not used for data encryption itself. This is a significant advantage 
over 802.1 1b in which the same key is used for authentication and encryption. 

In summary the known attacks on the EO cipher used in Bluetooth are far 
more computationally complex then corresponding attacks on RC4 used in 
802.11b. As yet, no practical direct attack has been reported. Also, unlike 
802.1 1 b, different keys are used for authentication and encryption. 
Accordingly practical studies on Bluetooth security have been focused on 
methods to guess or steal the key (or at least a portion of it). The most 
logical time to attempt this is during the pairing procedure. 

6.0 Bluetooth Pairing 

As discussed in Section 4.0 pairing is the procedure where a relationship (link 
key) is established between two previously unknown devices. The link key is 
cfer/Vecf when the devices are initially paired (i.e. the link key does not exist 
before the pairing procedure). Pairing is facilitated with yet another key, the 
initialization key. This key is computed by a pair of devices using the Bluetooth 
addresses of each device, a random number, and a shared secret (PIN). Since it 
is only used in the initial pairing, the initialization key is only used once. 

The initial pairing is the most profitable area of attack on a Bluetooth device. If 
the attacker can guess or steal the PIN during the initial pairing, then he can 
perform a much more efficient search to derive the link key. This search is 
further simplified if the communications occurring while the devices are paired is 
recorded [6]. For this reason the Bluetooth SIG strongly encourages the use of 
long, random PINs and suggests that pairing be performed only in a private 
place. Assuming that both devices have a man-machine interface (such as a 
keypad) it is also suggested that the PIN be manually entered into both devices 
or in any case communicated out-of-band (not transmitted over the Bluetooth 
wireless link). Thus, long PINs provide improved security since the PIN cannot 
be received over-the-air. To steal the PIN an attacker must guess or record it by 
some other means such as direct observation of the user, a more difficult 
procedure if the PIN is long and the pairing is performed in private. 

7.0 Final Comments 

The known attacks on 802. 11 b security have been discussed and found not to 
apply to Bluetooth wireless technology. In particular 



a) 802.1 1b authentication is highly susceptible to impersonation by recording 
only one authentication procedure. This is facilitated because a 
plaintext/ciphertext pair is transmitted. Bluetooth communications do not 
share this limitation. 

b) 802.1 1 b encryption is not very secure. The RC4 implementation used in 
802.1 1 b has several well-known direct attacks. Currently known direct 
attacks on the Bluetooth encryption are computationally complex and of 
little practical value. 



From the preceding discussion it is clear that the weakest link in the Bluetooth 
security architecture is the initial pairing especially if a weak PIN is used. 
Accordingly the Bluetooth SIG strongly encourages pairing in a private place and 
the use of robust PINs. In addition, simple devices that use unit keys should not 
be relied upon to communicate highly secure data. 

As a communication standard, Bluetooth security focuses on the link level. It 
provides both entity authentication and link privacy. Since these functions are 
focused at the lower network layers, message authentication and secure end-to- 
end links are not provided. However, many applications, such as e-mail and 
browser transactions require end-to-end security. As with other communication 
standards, this function is expected to be provided at higher network layers by 
specific application providers. Accordingly, the Bluetooth SIG encourages the 
reuse of existing transport, session and application layer security. 

Regarding the security limitations that have been reported for 802.1 lb; the 
WLAN community is currently examining these issues. We expect them to be 
resolved with subsequent revisions of the standard. In addition several 802.1 lb 
vendors have added proprietary authentication and encryption procedures at 
higher network layers. 

Acknowledgements 

The authors wish to thank the members of the Bluetooth Security Experts Group 
and also Brent Miller and Peter Lee from IBM for their helpful comments. 



References 

[1] W. A. Arbaugh, "Wireless Research", available from, 
http:/Avww.cs.umd.edii/-waaAvireless.html 

[2] J. Walker, "Unsafe at any key size; An analysis of the WEP encapsulation", 
available from http://grouper.ieee.Org/groups/802/l 1/Documents/DocumentHolder/O- 
362.zip 



[3] N. Borisov, I. Goldberg, and D. Wagner, "Intercepting Mobile Communications: The 
Insecurity of 802.1 1." available from http:/Avww.issac.sc.berklev.edu/issac/wep-faq.html. 

[4] S. Fluhrer, I. Mantin, A. Shamir, Weaknesses in the Key Scheduling Algorithm 
of RC4, in the Workshop Record of SAC 2001 

[5] W. Arbaugh, N. Shankar, Y.C.J. Wan, "Your 802.1 1 Wireless Network has No 
Clothes" available from http:/Avww.cs.umd.edu/-waaAvireless.pdf 

[6] M. Jakobsson and S. Wetzel, "Security Weaknesses in Bluetooth" available from 
http://vyww.rsasecurity.corn/rsalabs/stafFbios/miakobsson^luetooth^ 

[7] S. Fluhrer and S. Lucks, "Analysis of the EO Encryption System" available from S. 
Lucks' web site at http://th.informatik.uni-mannheim.de/People/Lucks/papers/eQ.ps.gz , a 
gnu- zipped Postscript file. 

[8] Bluetooth SIG, Specification of the Bluetooth system, Profiles",, Version 1.1,1 
February 22, 2001 , available at http://www.bluetooth.com/ . 

[9] Bluetooth SIG, Specification of the Bluetooth system, Core Version 1.1,1 February 
22, 2001, available at http://www.bluetooth.com/ . 



[10] B. Miller, "IEEE 802.1 1 and Bluetooth wireless technology" available from 
http://www- 1 06.ibm.com/developerworks/wireless/librarv/wi-phone/ 



Bluetooth WHITE R\PER 


OATH 

25 August 99 


N.B. 


DOCUMENT NO 

1.C.1 23/1.0 


RESPONSIBLE 

Riku Mettala 


E-MAIL ADDRESS 

Riku.Mettala@nmp.nokia.com 


STATUS 



Bluetooth PC Card Transport Layer 

V Version 1 .0 



'% 

\ \ \ \ 

\ \ \ 



\ 



i \ 



/ I I 



i 

/ / I 



/ / / 



/ 



The Bluetooth module can be connected to the 
Bluetooth host, e.g., a PC in various ways. One 
possibility is to place the module into a PC Card 
and the required communications is done between 
the PC and the PC Card. 



Bluetooth PC Card Transport Layer Page 2 of 9 



Special Interest Group (SIG) 

The following companies are represented in the Bluetooth Special Interest 
Group: 

Ericsson Mobile Communications AB 
IBM Corp. 
Intel Corp. 

Nokia Mobile Phones 
Toshiba Corp. 



Contributors 

Cooklev, Todor 3Com corporation 

Inouye, Jon Intel Corporation 

Mettala, Riku Nokia Mobile Phones 



Disclaimer and copyright notice 

THIS DRAFT DOCUMENT IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, 
INCLUDING ANY WARRANTY OF MERCHANTABILITY. NONINFRINGEMENT, FITNESS 
FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF 
ANY PROPOSAL, SPECIFICATION OR SAMPLE. All liability, including liability for 
infringement of any proprietary rights, relating to use of information in this document is 
disclaimed. No license, express or implied, by estoppel or otherwise, to any intellectual 
property rights are granted herein. 

This document is an intermediate draft for comment only and is subject to change without 
notice. Readers should not design products based on this document. 

Copyright © Nokia Mobile Phones 1999. *Third-party brands and names are the property of 
their respective owners. 



30 August 1999 



2 



Bluetooth PC Card Transport Layer 



Page 3 of 9 



Contents 



1 Overview 4 

2 Transport Functionality.... — 6 

2.1 Packet Types over Transport Layer 6 

3 PC Card Minidriver Requirements 7 

3.1 Interface with HCI Driver 7 

3.2 Interface with Physical Bus 7 

4 References. - 8 

5 Acronyms 9 



30 August 1999 



3 



Bluetooth PC Card Transport Layer 



Page 4 of 9 



1 Overview 



Bluetooth SIG (Special Interest Group) has defined that USB, RS232 (serial 
cable), UART, and PC Card are alternatives for a Bluetooth module to be 
connected with a PC (host). Bluetooth SIG has specified the standardized 
interfaces for the USB, RS232, and UART but the interface to the PC Card will 
not be standardized. The reasons for this are varied but the dependency of 
the interface on the PC Card implementation and the fact, that SIG does not 
want restrict the technology by standardizing the interface, are examples. 

The purpose of this white paper is to describe the general functionality how 
the PC Card communicates with the host and the general requirements for the 
SW component delivered within the Bluetooth PC Card product. However, the 
programming interface between the module within the PC Card and the host 
will not be specified according to the Bluetooth SIG decision. Manufacturers 
should use existing PC Card and Cardbus standards for designing their 
products along with existing PC and PDA guidelines regarding cards designed 
for these types of devices. 

Figure 1 depicts the components of the Bluetooth host and the Bluetooth 
module in the cases of the USB, RS232, and PC Card devices. UART is not 
included in the figure. The upper interfaces of the minidriver (USB, RS232, or 
PC Card minidriver) are the interfaces, which connect the transport layer to 
the rest of the Bluetooth SW protocol stack on the host. This interface (See 
also Chapter 3.1 ) and the lower interface of the HC driver comply with each 
other and so, a proper information can exchange between these drivers. 
However, the HC driver may not have any knowledge, which of the transport 
layer connects the host and the module. 
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Figure 1 USB, RS232, and PC Card Transport Layers 
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2 Transport Functionality 



The PC Card transport layer indicates and transfers the different types of HC 
packets using the physical bus from the host to the module and vice versa. 
Thus, the receiving end is able to separate the different packet types. Figure 2 
depicts this procedure. 
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Figure 2 Bluetooth PC Card Transport Layer Functionality 

2.1 Packet Types over Transport Layer 

There are at least four different packet types, which the transport protocol 
must recognize (See also Figure 2). These packet types are HCI commands, 
HCI events, ACL data, and SCO data. The transport layer (PC Card Driver or 
Bluetooth PC Card Firmware) has to get information about the packet types 
directly from the HCI driver or from the HC firmware. OthenA/ise, the transport 
layer is not able to fonA/ard the packet type information from the host to the 
module or vice versa. However, the PC Card transport layer has not to have 
any visibility into the payload data, which the HCI driver sends to the host 
controller in the module or vice versa. 



This document does not specify how the transport layer indicates the separate 
packet types. This depends on the different PC Card solutions. 
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3 PC Card Minidriver Requirements 



The purpose of the Bluetooth PC Card minidriver is to give a possibility for 
sending and receiving the HCI messages to and from the PC Card, 
respectively. The minidriver has to provide two interfaces such that this 
communication is possible. These interfaces are the interface with the HCI 
driver (the upper interface) and the interface with the physical bus (the lower 
interface), to which the PC Card is also physically connected. 

3.1 Interface with HCI Driver 

If the vendor implementing a Bluetooth PC Card and a Bluetooth PC Card 
minidriver also delivers the rest of the Bluetooth SW protocol stack, there are 
no external requirements to this interface and the interface can be vendor 
specific. Also, in this case a separate Bluetooth PC Card minidriver may not 
exist but it is integrated with the other drivers including the HCI driver. 

If the vendor delivers only the Bluetooth PC Card and the minidriver for it, the 
interface must comply with the lower interface of the HCI driver of an existing 
Bluetooth SW protocol stack implementation. 

3.2 Interface with Physical Bus 

There are no requirements for the lower interface of the Bluetooth PC Card 
minidriver. It is assumed that the Bluetooth PC Card including the PC Card 
firmware and the minidriver are provided by the same vendor. Thus, there will 
be no interoperability problems with the communications between the firmware 
and minidriver. 
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Asynchronous ConnectionLess 
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1 Introduction 



The Bluetooth Special Interest Group (SIG) has developed the Bluetooth 
Specification Version 1.0 Draft Foundation (thereafter to be referred to as the 
"Specification"), that allows for developing interactive services and 
applications over interoperable radio modules and data communication 
protocols. The objective of this paper is to provide an overview of the 
protocols in the Specification, their capabilities and the relation to each other 
(referred to as the "Bluetooth protocol architecture"). Moreover, a number of 
usage models identified by the Bluetooth SIG will be presented and it will be 
shown how (and which of) these protocols are stacked to support these usage 
models. 

1.1 Bluetooth Protocol Stack 

The ultimate objective of the Specification is to allow applications written in a 
manner that is conformant to the Specification to interoperate with each other. 
To achieve this interoperability, matching applications (e.g., corresponding 
client and server application) in remote devices must run over identical* 
protocol stacks. The following protocol list is an example of a (top-to-bottom) 
protocol stack supporting a business card exchange application: vCard -> 
OBEX RFCOMM L2CAP Baseband. This protocol stack contains both 
an internal object representation convention, vCard, and "over-the-air" 
transport protocols, the rest of the stack. 

Different applications may run over different protocol stacks. Nevertheless, 
each one of these different protocol stacks use a common Bluetooth data link 
and physical layer, see more details on the protocol layers in the next section. 
Figure 1 shows the complete Bluetooth protocol stack as identified in the 
Specification on top of which interoperable applications supporting the 
Bluetooth usage models are built. Not all applications make use of all the 
protocols shown in Figure 1. Instead, applications run over one or more 
vertical slices from this protocol stack. Typically, additional vertical slices are 
for services supportive of the main application, like TCS Binary (Telephony 
Control Specification), or SDP (Service Discovery Protocol). It is worth of 
mentioning that Figure 1 shows the relations how the protocols are using the 
services of other protocols when payload data needs to be transferred over 
air. However, the protocols may also have some other relations between the 
other protocols. E.g., some protocols (L2CAP, TCS Binary) may use LMP 
(Link Manager Protocol) when there is need to control the link manager. 
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Figure 1 Bluetooth Protocol Stack 

As seen in Figure 1, the complete protocx)! stack comprises of both Bluetooth- 
specific protocols like LMP and L2CAP, and non-Bluetooth-specific protocols 
like OBEX (Object Exchange Protocol) and UDP (User Datagram Protocol). In 
designing the protocols and the whole protocol stack, the main principle has 
been to maximize the re-use of existing protocols for different purposes at the 
higher layers, instead of re-inventing the wheel once again. The protocol re- 
use also helps to adapt existing (legacy) applications to work with the 
Bluetooth technology and to ensure the smooth operation and interoperability 
of these applications. Thus, many applications already developed by vendors 
can take immediate advantage of hardware and software systems, which are 
compliant to the Specification. The Specification is also open, which makes it 
possible for vendors to freely implement their own (proprietary) or commonly 
used application protocols on the top of the Bluetooth-specific protocols. Thus, 
the open Specification permits the development of a large number of new 
applications that take full advantage of the capabilities of the Bluetooth 
technology. 
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2 Protocols in Bluetooth Architecture 



The Bluetooth protocol stack can be divided into four layers according to their 
purpose including the aspect whether Bluetooth SIG has been involved in 
specifying these protocols. The protocols belong into the layers in the 
following way. 



Protocol layer 


Protocols in the stack 


Bluetooth Core Protocols 
Cable Replacement Protocol 
Telephony Control Protocols 
Adopted Protocols 


Baseband [i]^LMP [2]; L^^ ■ 
RFCOMM [5] 

TCS Binary [6], At-commands [7],i8],[9] 

PPP [10], UDP/TCP/IP [10], OBEX [11], WAP [12], 
vCard [13] , vCal [14], IrMC^ [15], WAE [16] 



Table 1: The protocols and layers in the Bluetooth protocol stack 



In addition to the above protocol layers, the Specification also defines a Host 
Controller Interface (HCI), which provides a command interface to the 
baseband controller, link manager, and access to hardware status and control 
registers. This interface is not discussed further in this paper, but more 
information can be obtained from the functional specification of Bluetooth host 
controller interface [17]. In Figure 1 , HCI- is positioned below L2CAP but this 
positioning is not mandatory but HCI can exist e.g., above L2CAP. 

The Bluetooth Core protocols comprise exclusively Bluetooth-specific 
protocols developed by the Bluetooth SIG. RFCOMM and the TCS binary 
protocol have also be developed by the Bluetooth SIG but they are based on 
the ETSI TS 07.10 [18] and the ITU-T Recommendation Q.931 [19], 
respectively. The Bluetooth Core protocols (plus the Bluetooth radio) are 
required by most of Bluetooth devices, while the rest of the protocols are used 
only as needed. 

Together, the Cable Replacement layer, the Telephony Control layer, and the 
Adopted protocol layer form application-oriented^ protocols enabling 
applications to run over the Bluetooth Core protocols. As mentioned earlier, 
the Bluetooth Specification is open and additional protocols (e.g., HTTP, FTP 
[10], etc.) can be accommodated in an interoperable fashion on top of the 
Bluetooth-specific transport protocols or on top of the application-oriented 
protocols shown in Figure 1. 



^ Not shown above OBEX in Figure 1. 

^ "Application-oriented" here is with respect to Bluetooth transport services and should be 
interpreted as any protocol layer, or application that runs on top of the Bluetooth-specific 
transport protocols. 
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2.1 Bluetooth Core Protocols 

2.1.1 Baseband 

The Baseband and Link Control layer enables the physical RF link between 
Bluetooth units fonning a piconet [1]. As the Bluetooth RF system is a 
Frequency-Hopping-Spread-Spectrum system in which packets are 
transmitted in defined time slots on defined frequencies, this layer uses inquiry 
and paging procedures to synchronize the transmission hopping frequency 
and clock of different Bluetooth devices. 

It provides 2 different kind of physical links with their corresponding baseband 
packets, Synchronous Connection-Oriented (SCO) and Asynchronous 
Connectionless (ACL) which can be transmitted in a multiplexing manner on 
the same RF link. ACL packets are used for data only, while the SCO packet 
can contain audio only or a combination of audio and data. All audio and data 
packets can be provided with different levels of FEC or CRC error correction 
and can be encrypted. 

Furthermore, the different data types, including link management and control 
messages, are each allocated a special channel. 

2.11^ Audio 

Audio data can be transferred between one or more Bluetooth devices, 
making various usage models possible and audio data in SCO packets is 
routed directly to and from Baseband and it does not go through L2CAP. 
Audio model is relatively simple within Bluetooth; any two Bluetooth devices 
can send and receive audio data between each other just by opening an audio 
link. 

2.1 .2 Link Manager Protocol 

The link manager protocol [2] is responsible for link set-up between Bluetooth 
devices. This includes security aspects like authentication and encryption by 
generating, exchanging and checking of link and encryption keys and the 
control and negotiation of baseband packet sizes. 

Furthermore it controls the power modes and duty cycles of the Bluetooth 
radio device, and the connection states of a Bluetooth unit in a piconet. 

2.1.3 Logical Link Control and Adaptation Protocol 

The Bluetooth logical link control and adaptation protocol (L2CAP) [3] adapts 
upper layer protocols over the baseband. It can be thought to work in parallel 
with LMP in difference that L2CAP provides services to the upper layer when 
the payload data is never sent at LMP messages. 
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L2CAP provides connection-oriented and connectionless data services to the 
upper layer protocols with protocol multiplexing capability, segmentation and 
reassembly operation, and group abstractions. L2CAP permits higher level 
protocols and applications to transmit and receive L2CAP data packets up to 
64 kilobytes in length. 

Although the Baseband protocol provides the SCO and ACL link types, 
L2CAP is defined only for ACL links and no support for SCO links is specified 
in Bluetooth Specification 1.0. 

2.1.4 Service Discovery Protocol (SDR) 

Discovery services are crucial part of the Bluetooth framework. These services 
provide the basis for all the usage models. Using SDP, device information, 
services and the characteristics of the services can be queried and after that, 
a connection between two or more Bluetooth devices can be established. SDP 
is defined in the Service Discovery Protocol specification [4]. 

2.2 Cable Replacement Protocol 
2.2.1 RFCOMM 

RFCOMM is a serial line emulation protocol and is based on ETSI 07.10 
specification. This "cable replacement" protocol emulates RS-232 control and 
data signals over Bluetooth baseband, providing both transport capabilities for 
upper level services (e.g. OBEX) that use serial line as transport mechanism. 
RFCOMM is specified in [5]. 

2.3 Telephony Control Protocol 

2.3.1 Telephony Control - Binary 

Telephony Control protocol - Binary (TCS Binary or TCS BIN) [6], a bit- 
oriented protocol, defines the call control signaling for the establishment of 
speech and data calls between Bluetooth devices. In addition, it defines 
mobility management procedures for handling groups of Bluetooth TCS 
devices. TCS Binary is specified in the Bluetooth Telephony Control protocol 
Specification Binary, which is based on the ITU-T Recommendation Q.931 
[19], applying the symmetrical provisions as stated in Annex D of Q.931 

2.3.2 Telephony Control - AT Commands 

Bluetooth SIG has defined the set of AT-commands by which a mobile phone 
and modem can be controlled in the multiple usage models (See Chapters 3.2 
and 3.6). In Bluetooth, AT-commands, which are utilized, are based on ITU-T 
Recommendation V.250 [20] and ETS 300 916 (GSM 07.07) [21]. In addition, 
the commands used for FAX services are specified by the implementation. 
These may be either: 

• Fax Class 1 .0 TIA-578-A [22] and ITU T.31 Service Class 1 .0 [23] 



Protocols in Bluetooth Architecture 29 September 1999 



8 



Bluetooth Protocol Architecture 



Page 9 of 20 



• Fax Class 2.0 TIA-592 [24] and ITU T.32 Service Class 2.0 [25] 

• Fax Service Class 2 - No industry standard 

2.4 Adopted Protocols 
2A1 PPP 

In the Bluetooth technology, PPP is designed to run over RFCOMM to 
accomplish point-to-point connections. PPP is the IETF Point-to-Point Protocol 
[10] and PPP-Networking is the means of taking IP packets to/from the PPP 
layer and placing them onto the LAN. Usage of PPP over Bluetooth is 
described in [26]. 

2.4.2 TCP/UDP/IP 

These protocol standards are defined by the Internet Engineering Task Force 
and used for communication across the Internet [10]. Now considered as the 
most widely used protocol family in the world, TCP/IP stacks have appeared 
on numerous devices including printers, handheld computers, and mobile 
handsets. Access to these protocols is operating system independent, 
although traditionally realized using a socket programming interface model. 
The implementation of these standards in Bluetooth devices allows for 
communication with any other device connected to the Internet: The Bluetooth 
device, should it be a Bluetooth cellular handset or a data access point for 
example is then used as a bridge to the Internet. 

TCP/IP/PPP is used for the all Internet Bridge usage scenarios in Bluetooth 
1 .0 and for OBEX in future versions [11]. UDP/IP/PPP is also available as 
transport for WAP [12]. 

2.4.3 OBEX Protocol 

IrOBEX [27] (shortly OBEX) is a session protocol developed by the Infrared 
Data Association (IrDA) to exchange objects in a simple and spontaneous 
manner. OBEX, which provides the same basic functionality as HTTP but in a 
much lighter fashion, uses a client-server model and is independent of the 
transport mechanism and transport API, provided it realizes a reliable 
transport base. Along with the protocol itself, the "grammar" for OBEX 
conversations between devices, OBEX also provides a model for representing 
objects and operations. In addition, the OBEX protocol defines a folder-listing 
object, which is used to browse the contents of folders on remote device. 

In the first phase, RFCOMM is used as sole transport layer for OBEX [11]. 
Future implementations are likely to support also TCP/IP as a transport. 

2.4.3.1 Content Formats 

vCard [13] and vCalendar [14] are open specifications developed by the versit 
consortium and now controlled by the Internet Mail Consortium. These 
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specifications define the format of an electronic business card and personal 
calendar entries and scheduling information, respectively. vCard and 
vCalendar do not define any transport mechanism but only the fonnat under 
which data is transported. By adopting the vCard and vCalendar, the SIG will 
help further promote the exchange of personal information under these well- 
defined and supported formats. The vCard and vCalendar specifications are 
available from the Internet Mail Consortium and are being further developed 
by the Internet Engineering Task Force (IETF). 

Other content formats, which are transferred by OBEX in Bluetooth, are 
vMessage and vNote [15]. These content formats are also open standards 
and are used to exchange messages and notes. They are defined in the IrMC 
specification, which also defines a format for the log files that are needed 
when synchronizing data between devices. 

2,4.4 WAP 

Hidden computing usage models can be implemented using the WAP 
features. Bluetooth as a WAP Bearer is defined in [12]. 

The Wireless Application Protocol (WAP) Forum is building a wireless protocol 
specification [16] that works across a variety of wide-area wireless network 
technologies. The goal is to bring Internet content and telephony services to 
digital cellular phones and other wireless terminals. In Figure 2, the protocol 
stack of the WAP framework is depicted. 




Figure 2 WAP Framework 

The idea behind the choice of WAP is to reuse the upper software applications 
developed for the WAP Application Environment (WAE). These include WML 
and WTA browsers that can interact with applications on the PC. Building 
application gateways which mediate between WAP servers and some other 
application on the PC makes it possible to implement various hidden 
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computing functionality, like remote control, data fetching from PC to handset 
etc. WAP servers also allow for both content push and pull between PC and 
handset, bringing to life concepts like information kiosks. 

WAP framework also opens up the possibility of custom applications for 
handsets that use WML and WML Script as "universal" Software Development 
Kit. 

2.4.4.1 Content Formats 

Supported content formats for WAP over Bluetooth are WML, WMLScript, 
WTA event, WBMP, and vCard/vCal. These are all part of WAE. More 
information on WAE can be found from [16]. 
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3 Bluetooth Usage Models and Protocols 

In this chapter, the highest priohty usage models identified by the SIG's 
marketing group are briefly introduced. Each usage model is accompanied by 
a Profile. Profiles define the protocols and protocol features supporting a 
particular usage model. Bluetooth SIG has specified the profiles for these 
usage models. In addition to these profiles, there are four general profiles that 
are widely utilized by these usage model oriented profiles. These are the 
generic access profile (GAP) [28], the serial port profile [29], the service 
discovery application profile (SDAP) [30], and the generic object exchange 
profile (GOEP) [31]. 

3.1 File Transfer 

The file transfer usage model (See also the file transfer profile [32]) offers the 
ability to transfer data objects from one device (e.g., PC, smart-phone, or 
PDA) to another. Object types include, but are not limited to, .xls, .ppt, .wav, 
.jpg, and .doc files, entire folders or directories or streaming media formats. 
Also, this usage model offers a possibility to browse the contents of the folders 
on a remote device. 

In addition, simple push and exchange operations, e.g., business card 
exchange are covered in the object push profile [33], with vCard specified as 
the format for pushed business card content. 

In Figure 3, the required protocol stack presented for this usage model is 
presented. The figure does not show the LMP, Baseband, and Radio layers 
although those are used underneath (See Figure 1). 



3.2 Internet Bridge 

In this usage model, mobile phone or cordless modem acts as modem to the 
PC, providing dial-up networking [8] and fax [9] capabilities without need for 




Figure 3 Protocol Stack for File Transfer Applications 
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physical connection to the PC, The dial-up networking scenario of this usage 
model needs a two-piece protocol stack (in addition to the SDP branch), which 
is shown in Figure 4. The AT-commands are needed to control the mobile 
phone or modem and another stack (E.g., RPR over RFCOMM) to transfer 
payload data. The fax scenario has a similar protocol stack but RPR and the 
networking protocols above RPR are not used and the application software 
sends a facsimile directly over RFCOMM. 



Modem Emulation or Driver application 

















Figure 4 Dial-up Networking Protocol Stack 

3.3 LAN Access 

In this usage model (See also the LAN access profile [26]), multiple data 
terminals (DTs) use a LAN access point (LAP) as a wireless connection to a 
Local Area Network (LAN). Once connected, the DTs operate as if it they were 
connected to the LAN via dialup networking. The DT can access all of the 
services provided by the LAN. The protocol stack is nearly identical to the 
protocol stack in the Internet bridge usage model except that the AT- 
commands are not used. The protocol stack is represented in Figure 5. 




Figure 5 Protocol Stack of LAN Access (PPP) Usage Model 
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3.4 Synchronization 

The synchronization usage model [34] provides a device-to-device (phone, 
PDA, computer, etc.) synchronization of the PIM (personal information 
management) information, typically phonebook, calendar, message, and note 
information. Synchronization requires business card, calendar and task 
information to be transferred and processed by computers, cellular phones 
and PDAs utilizing a common protocol and format. The protocol stack for this 
usage model is presented in Figure 6. In the figure, the synchronization 
application block represents either an IrMC client or an IrMC server software. 




Figure 6 Protocol Stack for Synchronization 

3.5 Three-in-One Plione 

Telephone handsets built to this profile may connect to three different service 
providers. First, telephones may act as cordless phones connecting to the 
public switched telephone network (PSTN) at home or the office and incurring 
a fixed line charge. This scenario [35] includes making calls via a voice 
basestation, making direct calls between two terminals via the basestation and 
accessing supplementary services provided by an external network. Second, 
telephones can connect directly to other telephones for the purpose of acting 
as a "walkie-talkie" or handset extension. Referred to as the intercom scenario 
[36], the connection incurs no addifional charge. Third, the telephone may act 
as a cellular phone connecting to the cellular infrastructure and incurring 
cellular charges. The cordless and intercom scenarios use the same protocol 
stack, which is shown in Figure 7. The audio stream is directly connected to 
the Baseband protocol indicated by the L2CAP bypassing audio arrow. 
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Figure 7 Protocol Stack for Cordless Phone and Intercom Scenarios 

3.6 Ultimate Headset 

The headset can be wirelessly connected for the purpose of acting as a 
remote device's audio input and output interface. The headset increases the 
user's freedom of movement while maintaining call privacy. A common 
example is a scenario where a headset is used with either a cellular handset, 
cordless handset, or personal computer for audio input and output. The 
protocol stack for this usage model is depicted in Figure 8 [7]. The audio 
stream is directly connected to the Baseband protocol indicated by the L2CAP 
bypassing audio arrow. The headset must be able to send AT-commands and 
receive result codes. This ability allows the headset to answer incoming calls 
and then terminate them without physically manipulating the telephone 
handset. 




Figure 8 Ultimate Headset Protocol Stack 
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4 Summary 



The Bluetooth protocols are intended for rapidly developing applications using 
the Bluetooth technology. The lower layers of the Bluetooth protocol stack are 
designed to provide a flexible base for further protocol development. Other 
protocols, such as RFCOMM, are adopted from existing protocols and these 
protocols are only modified slightly for the purposes of Bluetooth, The upper 
layer protocols are used without modifications. In this way, existing 
applications may be reused to work with the Bluetooth technology and the 
interoperability is ensured more easily. 

The purpose of the Specification is to promote the development of 
interoperable applications targeted at the highest priority usage models 
identified by the SIG's marketing team. However, the Specification also 
services as a framework for further development. Naturally, vendors are 
encouraged to invent more usage models within this framework. Using the 
Bluetooth technology with the capabilities of current computers and 
communications devices, the possibilities for new future wireless applications 
are unlimited. 
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6 Acronyms 



Abbreviation or 
Acronym 


Meaning 


ACL 


Asynchronous ConnectionLess 


API 


Application Programming Interface 


CRC 


Cyclic Redundancy Check 


DT 


Data Terminal 


FEC 


Forward Error Correction 


FTP 


File Transfer Protocol 


GAP 


Generic Access Profile 


GOEP 


Generic Object Exchange Profile 


HCI 


Host Controller Interface 


HTTP 


HyperText Transfer Protocol 


IETF 


Internet Engineering Task Force 


IP 


Internet Protocol 


IrDA 


Infrared Data Association 


IrMC 


Ir Mobile Communications 


LAN 


Local Area Network 


lAP 


LAN Access Point 


LMP 


Link Manager Protocol 


L2CAP 


Logical Link and Control Adaptation Protocol 


OBEX 


Object Exchange Protocol 


PDA 


Personal Digital Assistant 


PIM 


Personal Information Management 


PPP 


Point-to-Point Protocol * 


PSTN 


Public Switched Telephony Network 


RFCOMM 


Serial Cable Emulation Protocol 


SCO 


Synchronous Connection-Oriented 


SDAP 


Service Discovery Application Profile 


SDP 


Service Discovery Protocol 


TCP/UDP 


Transport Control Protocol/User Datagram Protocol 
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Abbreviation or 
Acronym 


Meaning 


TCS Binary 


Telephony Control Specification - Binary 


WAE 


Wireless Application Environment 


WAP/ 


Wireless Application Protocol 


WML 


Wireless Markup Language 
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1 Introduction 



The Bluetooth specification includes security features at the link level. It 
supports authentication (unidirectional or mutual) and encryption. These 
features are based on a secret link key that is shared by a pair of devices. To 
generate this key a pairing procedure is used when the two devices 
comnnunicate for the first time. 

The link level functions are defined in the Bluetooth Baseband and the Link 
Manager Protocol Specifications (see [1] and [2]). More comprehensive 
descriptions can be found in the Bluetooth '99 conference proceedings (see 
[3], [4]). 

The Bluetooth profiles describe how to use the Bluetooth protocols in an 
interoperable way. Concerning security this is done in the Generic Access 
Profile [5], which also defines terms used throughout this white paper. This 
profile specifies three security modes for a device: 

• Security mode 1 (non-secure): A device will not initiate any security 
procedure. 

• Security mode 2 (service-level enforced security): A device does not 
initiate security procedures before channel establishment at L2CAP level. 
This mode allows different and flexible access policies for applications, 
especially running applications with different security requirements in 
parallel. 

• Security modes 3 (link level enforced security): A device initiates security 
procedures before the link set-up at the LMP level is completed. 

This white paper deals with security mode 2. It describes how flexible security 
mechanisms can be implemented. The contents of this white paper serve only 
as an implementation guideline and do not represent a Bluetooth specification, 
since this is device specific and not required for interoperability. 

Chapter 2 lists the requirements and design objectives leading to the 
definitions of this flexible architecture and the limitations. Chapter 3 describes 
a possible architecture using a central security manager. 
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2 Functionality & Limitations 



This chapter describes the functionality of the architecture explained in 
Chapter 3. This can also be seen as a summary what can be built on top of 
security mode 2 (service-level enforced security, see [5]). 

2.1 Security Levels 

• It is possible to define different security levels for devices and services. 

• For devices two trust levels are distinguished: 

- Trusted Device: Device with fixed relationship (paired) that is 
trusted and has unrestricted access to all services. 

- Untrusted Device; Device with no permanent fixed relationship 
(but possibly a temporary one) or device that has a fixed 
relationship, but is not considered as trusted. The access to 
services is restricted. 

A possible refinement is to set the trust level of a device specifically for 
services or a group of services. The interaction with the remote device does 
not exclude the implementation of such refined access policies. 

• For services the requirement for authorisation, authentication and 
encryption are set independently (although some restrictions apply). The 
access requirements allow to define three security levels: 

- Services that require authorisation and authentication. 
Automatic access is only granted to trusted devices. Other- 
devices need a manual authorisation. 

- Services that require authentication only. Authorisation is not 
necessary. 

- Services open to all devices; authentication is not required, no 
access approval required before service access is granted. 

• A default security level is defined to serve the needs of legacy applications. 
This default policy will be used unless other settings are found in a 
"security" database related to a service, e.g., an internal security 
information database. 

2.2 Flexibility and Usability 

• It is possible to grant access to some services without providing access to 
other services (example: On a cellular phone, Service Discovery records 
shall be accessible, whereas dialup networking shall only be available for 
specific devices.) 

• The security architecture supports security policies for devices with some 
services communicating with changing remote devices (example: File 
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Transfer or Business Card Exchange). Access granted to a service on 
such device does 

- not open up access to other services on the device. 

- not grant future access automatically or in an uncontrolled way 
to services on the device. 

• User intervention for access to services is avoided as much as possible. It 
is only needed to allow devices limited access to services or for setting up 
trusted relationship with devices allowing unlimited access to services. 

• This architecture does not deal with application level security, but such 
concepts are not excluded. 

2.3 Implementation and Bluetooth-specific Matters 

• The security architecture accounts for Bluetooth multiplexing protocols at 
and above L2CAP. At present, only RFCOMM is considered, as all other 
protocols are not Bluetooth-specific, and some have their own security 
features. 

• The security architecture allows different protocols to enforce the security 
policies. For example, L2CAP will enforce the Bluetooth security policy for 
cordless telephony, RFCOMM will enforce the Bluetooth security policy for 
dialup networking, and OBEX will use its own security policy for file transfer 
and synchronisation. 

• The architecture can completely work using security mode 2 of the Generic 
Access Profile. Especially since there are no changes to Baseband and 
LMP functions for authentication and encryption. 

• Authentication and encryption are set for a physical connection (i.e., on 

baseband level). 

• Lower layers are not aware of service/application layer security. 

• The enforcement policy for authentication, authorisation or encryption might 
be different for client and server role. The security level of peer entities 
running an application needs not to be symmetric. 

2.4 Risks and Limitations: 

The following scenarios have been considered in identifying the limitations. 

• Scenario 1: There are two Bluetooth devices (e.g., PDAs). Each device 
has a set of applications: calendar, file synchronization, etc. The two 
devices will communicate, over a Bluetooth link, to perform a certain task 
such as file synchronization. 

• Scenario 2: There are more than two of scenario 1 devices. All devices will 
communicate over Bluetooth links to perform tasks that do not require 
security such as exchanging business cards. 
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• Scenario 3: A small device such as a PDA requires access, over a 
Bluetooth link, to infrastructure services: the Internet, e-commerce 
applications, corporate database, etc. Such device will be connected to a 
"LAN Access Point" over the BT link. The LAN Access Point will be 
connected to the infrastructure services via a wired or wireless LAN. This is 
a 3-tier configuration where tier 1 is the small device, tier 2 is the LAN 
Access Point, and tier 3 is the Infrastructure Services. 

The Bluetooth Security architecture has the following limitations: 

1 . Support for legacy applications: In all scenarios, the legacy application will 
not make calls to the security manager. Instead a Bluetooth-aware 
"adapter*' application is required to make security-related calls to the 
Bluetooth security manager on behalf of the legacy application. 

2. Only a device is authenticated and not its user. If there is a need for 
authentication of the user, other means - e.g., application level security 
features - will be necessary. 

3. Refer to scenario 1 . There is no mechanism defined to preset 
authorisation per service. However, a more flexible security policy can be 
implemented with this architecture, without a need to change the Bluetooth 
protocol stack. Of course, modifications of the security manager and the 
registration processes would be necessary. 

4. The approach only allows access control at connection set-up. The access 
check can be asymmetric, but once a connection is established, data flow 
is in principle bi-directional. It is not possible within the scope of this 
architecture to enforce unidirectional traffic. 

5. Support for the 3-tier configuration in scenario 3: The security architecture 
presented in this paper is built upon the Bluetooth baseband security 
procedures that addresses the BT link security and mutual device 
authentication at each end of the link. To address the end-to-end security 
issue present in cases like in scenario 3, this paper assumes the existence 
of a "higher-level" end-to-end security solution which may utilize the 
Bluetooth security architecture presented for accessing devices and 
services directly present at the two ends of a Bluetooth link. This higher- 
level security solution is outside the scope of this paper. 
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3 Security Architecture to meet the Requirements 

This chapter describes an approach for a flexible security architecture built on 
top of the link-level security features of Bluetooth. 

3.1 Overview 

The general architecture is shown in Figure 1. The key component is a 
security manager with the following tasks: 

• Store security-related information on services 

• Store security-related information on devices 

• Answer access requests by protocol implementations or applications 
(access granted or refused) 

• Enforce authentication and/or encryption before connecting to the 
application. 

• Initiate or process input from an ESCE^ (e.g., the device user) to set-up 
trusted relationships on device level. 

• Initiate pairing and query PIN entry by the user. PIN entry might also be 
done by an application. 

More details will be described in the following sections. 

This approach is devoted to connection-oriented L2CAP channels. The 
sections up to 3.4 only deal with this. For connectionless L2CAP data 
transmission, restrictions apply, which will be discussed in Section 3.5. 

The security architecture presented in this paper provides a very flexible 
security framework. This framework dictates when to involve a user (e.g., to 
provide a PIN) and what actions the underlying BT protocol layers follow to 
support the desired security check-ups. Within this framework, a number of 
realizations of the presented architecture can be instantiated, some of them 
simpler and some of them more advanced than the one discussed in detail in 
this paper, without moving outside the scope of the architecture. 



^ ESCE stands for "External Security Control Entity." ESCE typically represents a hunnan 
operating a device who decides how to proceed with security related matters, e.g., provide a 
PIN whenever needed, decide to create a trust relation with a device, etc. In general though, 
an ESCE represents an entity with the authority and knowledge to make decisions on how to 
proceed in a manner consistent to this security architecture. It could be a device user, or a 
utility application executed on behalf of the user based on preprogrammed security policies. In 
the latter case, this utility could reside within or outside a particular BT-enabled device. 
Without lack of generality, in the sequel the terms "ESCE" and "user" will be used 
interchangably and without any distinction. 
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User Interface 



Application 



Application 




RFCOMM 
(or other multiplexing 
protocol) 



► 



L2CAP 



Security 
Manager 



General 
Mgnnt 
Entity 



Service 
DatabasE 



Device 
Database 



HCI 



Link Manager / Link Controller 




Figure 1 : Security Architecture 

This approach with a centralised security manager allows easy 
implementation of flexible access policies, because the interfaces to protocols 
and other entities are kept simple and are limited to query/response and 
registration procedures. The policies for access control are encapsulated in 
the security manager. Therefore, implementation of more complex policies 
would not affect implementation of other parts. 

Implementations may decide, who performs the registration task, e.g., the 
application itself or a general management entity, responsible for setting the 
path in the protocol stack and/or registering the service at service discovery. 
This will be further discussed in Section 3.3.4. 

3.2 Security Levels 

3.2.1 Authorisation and Authentication 



We distinguish between authentication and authorisation. The terms are 
defined as follows: 
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Authentication is the process of verifying 'who' is at the other end of the link. 
Authentication is performed for devices (BD_ADDR). In Bluetooth this is 
achieved by the authentication procedure based on the stored link key or by 
pairing (entering a PIN). 

Authorisation is the process of deciding if device X is allowed to have access 
to service Y. This is where the concept of 'trusted' exists. Trusted devices 
(authenticated and indicated as "trusted"), are allowed access to services. 
Untrusted or unknown devices may require authorisation based on user 
interaction before access to services is granted. This does not principally 
exclude that the authorisation might be given by an application automatically. 
Authorisation always includes authentication. 

3.2.2 Device Trust Level 

We distinguish between two different device trust levels: 

Trusted Device: The device has been previously authenticated, a 

link key is stored and the device is marked as 
"trusted" in the Device Database. 

Untrusted Device: The device has been previously authenticated, a 

link key is stored but the device is not marked as 
"trusted" in the Device Database 

Unknown Device: No security information is available for this 

device. This is also an untrusted device. 

There will be a database table maintained in the security manager (see 
below). This database might be maintained for all services together (normal 
case referred to throughout this paper) or separately for each service or group 
of services. 

3.2.2. 1 Authenticate trusted device 

The verification is done using the authentication procedure, defined in the 
LMP and Baseband specifications. A device is verified as trusted, if a positive 
authentication response is given and the trusted flag is set. 

3.2.2.2 Set-up of the trusted relationship 

A trusted relationship is established during the pairing procedure. This is 
usually performed during the bonding procedure but could be performed at 
connection set-up. 

When an untrusted device is authorised to use a service, it is also possible to 
add it to the list of trusted devices during the same procedure. This of course 
requires an active selection by the user. 
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3.2.2.3 Authenticate untrusted device 

Authentication of untrusted devices is done similarly as for trusted devices 
with the exception that the device is not marked as trusted in the internal 
database. 

3.2.3 Security Level of Services 

The security level of a service is defined by three attributes: 

Authorisation Required: Access is only granted automatically to 

trusted devices (i.e., devices marked as 
such in the device database) or untrusted 
devices after an authorisation procedure. 

Authorisation always requires 
authentication to verify that the remote 
device is the right one. 

Authentication Required: Before connecting to the application, the 

remote device must be authenticated 

Encryption Required: The link must be changed to encrypted 

mode, before access to the service is 
possible 

This information is stored in the service database of the security manager. 

If no registration has taken place, a default security level is used. This default 
is: 

Incoming Connection: Authorisation and Authentication required 
Outgoing Connection: Authentication required 



3.3 Connection Set-up Procedure 
3.3.1 General Concept 

To meet different requirements on availability of services without user 
intervention, we must perform the authentication after determining what the 
security level of the requested service is. Thus, the authentication cannot be 
performed, when the ACL link is established. The authentication is perfomned, 
when a connection request to a service is submitted. 

Figure 2 illustrates the information flow for access to a trusted service. This is 
intended to be an example to understand and discuss the basic principles. 
The details will be described further below. 
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HCI 



Link Manager / Link Controller 



Figure 2: Information flow for access to trusted service 



The following procedures are performed: 

1. Connect request to L2CAP 

2. L2CAP requests access from the security manager. 

3. Security manager: lookup in service database 

4. Security manager: lookup in device database 

5. If necessary, security manager enforces authentication and 
encryption 

6. Security manager grants access 

7. L2CAP continues to set-up the connection. 



Authentication can be performed in both directions, client authenticates server 
and vice versa. 

3.3.2 Authentication on Baseband Link Set-up 

Although not targeted to security mode 3 (link level enforced security, see [5]), 
this architecture can support this mode as well. The security manager can 
command the link manager to enforce authentication before accepting a BB 
connection using the HCI. Different modes could be implemented in parallel: 

• authentication on BB connection 

• authentication on connection to the applications 

Clearly, they cannot run simultaneously, so if both are implemented, a 
decision has to be made somewhere. Before transitioning from mode 2 to 
mode 3, it must be ensured that untrusted devices do not get unwanted 
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access. To achieve this, the security manager can remove any link keys for 
untrusted devices stored in the radio module. The security manager can use 
the HCI. 

3.3.3 Handling for Protocol Stack 

For incoming connections, the access control procedure is described in Figure 
3 for incoming connections. Access control is required at L2CAP and in some 
cases additionally at multiplexing protocols above (e.g., RFCOMM). When 
receiving a connection request, the protocol entity queries the security 
manager, providing any multiplexing information it received with the connect 
request. The security manager makes a decision whether access is granted or 
refused and replies to the protocol entity. If access is granted, the connection 
set-up procedure is continued. If access is refused, the connection is 
terminated. 



If no access control is performed on a protocol layer, no interaction takes 
place with the security manager or other entities. 



1 



Non-Multiplexing Protocol 










Multiplexing Protocol 


^ — *- 


(e.g. RFCOMM) 





Security 
Manager 



L2CAP ^ 

f 

Figure 3: Behaviour ofProtocois for incoming Connections 



In this model we have two queries (e.g., function calls) to the security ' 
manager. The security manager should be able to store information on 
existing authentications . This avoids multiple authentication procedures on 
LMP level (i.e., over the air) within the same session. 

Thus, RFCOMM will do a policy check call to security manager. This will 
require an additional function call but not necessarily an additional 
authentication. 



For outgoing connections, a security check might also be required to achieve 
mutual authentication (authorisation is probably not useful here in most 
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cases). A similar procedure is carried out. Tine most elegant way is of course, 
if the applications submit requests to the security manager directly. If this is 
not possible (e.g., legacy applications), queries to the security manager are 
submitted by all multiplexing protocols from top to bottom, see Figure 4. 



i 



Non-Multiplexing Protocol 



I 



Multiplexing Protocol 
(e.g. RFCOMM) 



Security 
Manager 



L2CAP ^ 
Figure 4: Behaviour of Protocols for outgoing Connections 



3.3.4 Registration Procedures 

As mentioned in section 3.1, the security manager maintains security 
information for services in security databases, the implementation of which is 
outside the scope of this paper. Applications must register with the security 
manager before becoming accessible, see Figure 5. 



Application 
(or general management 
entity) 



Security Level, 
PSM, 

Protocol Info 



Non-Multiplexing Protocol 



Multiplexing Protocol 
(e.g. RFCOMM) 



Security Level 
for access from 
below 



Security 
Manager 
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Figure 5: Registration Processes 

Applications or their security delegate must provide their security level and 
multiplexing information (This is somewhat similar to the information registered 
to service discovery. The latter is required for the security manager to make a 
decision on a request submitted by a protocol entity as this entity will not know 
about the final application in most cases). 

Multiplexing protocol implementations performing queries at the security 
manager should register the policy for accessing them from below. 

Both registrations can also be done by the entity that is responsible for setting 
the path in the BT protocol stack. It is implementation-dependent, which entity 
does the registration (note: combining the service and security registration 
processes is not excluded). 

If no registration has taken place, the security manager will assume the 
default security level to make a decision on access see Section 3.2.3. 

L2CAP does not require registration here. It is the first multiplexing protocol in 
the Bluetooth stack and there will be a query for every connection request, 

3.3.5External Key Management 

This architecture does not exclude use of external key management 
procedures. Key management applications can distribute PINs or the link keys 
directly.^ In this case though, one needs to proceed with caution to maintain 
proper interoperability of the BT-enabled devices. 

3.4 Access Control Procedures 

This section gives an example how the access control can be handled in the 
security manager. Other solutions with the same functionality and/or the same 
security level are possible. 



^ It is not possible to provide the encrpytion keys from outside the module. 
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Figure 6: Example Flow Chart for Access Check by the security manager 
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authentication 
fail 





Figure 7: Example Flow Chart for Authentication Procedure 
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create trust ? 



Figure 8: Example Flow Chart for Authorisation Procedure 



3.5 Connectionless L2CAP 

As the security check is performed at a connection request to L2CAP to set-up 
a connection to the next higher protocol or application, the security check of 
connectionless data packets cannot be performed in that way. It is not 
practical to perform a security check on each single connectionless data 
packet. Therefore, a general policy of handling connectionless packets has to 
be made at L2CAP level. 

L2CAP offers the possibility to block connectionless traffic. This block can be 
done for a single protocol (PSM) on top of L2CAP, a list or all protocols. The 
same choices are possible for enabling connectionless traffic. 
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The security manager should check, whether there is any service in the 
service data base that does not permit connectionless data packets. The 
security manager will then initiate the enabling/disabling accordingly. 

If connectionless packets are passed, there will be no security check. It is then 
up to the protocol above L2CAP to make sure that no unacceptable security 
problem occurs. It will always be known, whether the data came in via 
connectionless or connection-oriented mode, but for connectionless packets 
the originiator is not known or verifiable. 
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4 Interfaces and Functions of the Security Manager 



This chapter describes a possible set of interfaces and functions for the 
security manager. The interactions are modelled as function calls. This 
chapter is meant as an implementation example. Clearly, the internal 
interfaces have no impact on interoperability with remote devices. 

4.1 Databases 

The security manager that implements the security architecture in this paper 
has to maintain several databases (or in general "information lists"). 

For the database tables the following abbreviations are used: 



• "M" for mandatory to support 

• "O" for optional to support 

• "C" for conditional to support 

The statements mandatory, optional or conditional are relative to the 
discussed realization of the security architecture. Clearly, simpler or more 
elaborate realizations of the security implementation may have other 
mandatory, conditional, or optional entires. 

4.1.1 Service Database 

The service database has to maintain the following security-related entries for 
each service. This could be stored in non-volatile memory or the services 
register at start-up. 



Authorisation Required: 


M 


Boolean 


Authentication Required: 


M 


Boolean 


Encryption Required: 


M 


Boolean 


PSM Value 


M 


Uintie 


Broadcasting allowed 


O 


Boolean 


other routing information 


C 


Structure TBD (only when 
needed) 



4.1.2 Device Database 

The trust information has to be stored in non-volatile memory. If entries are 
deleted for some reason, the respective device is treated an unknown, i.e., set 
to the default access level as defined in 3.2.3. 



BD ADDR 



M 



48 Bit IEEE address 
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trust level 


M 


Trusted / untrusted 


link key 


M 


Bit field (length up to 128 bit) 


device name 


0 


String (can be used to avoid 
name request) 



Note: It would also possible to store key information in a different way. 
4.1.3 Temporary Storage 

There are some data that should be stored to reduce overhead on the air 
interface. For each Baseband link: 

■ Authentication status 

■ Encryption status 
4.2 Interface to L2CAP 

L2CAP asks the security manager for access rights to a service on incoming 
and outgoing connection requests. There is no registration procedure since 
L2CAP is mandatory in Bluetooth protocol stacks. 

access := SEC_accessRequest ( 
Protocolldentification, 
Channelldentification, 
BD_ADDR, 
ConnectionHandle 
IncomingConnection 

); 



Parameter 


I/O 


Type 


Content 


access 


ret^ 


boolean 


true = granted 
false = denied 


Protocolldentification 


in 


uint32 


Number assigned to identify, 
which protocol has submitted 
the query 

The value is set to zero in case 
of L2CAP. 


PSM 


in 


uint32 


The channel is identified by the 
PSM value of next protocol in 



^ "ret" stands for the value "returned" by a function call; "in" stands for the "Input" parameters 
to a function call; "out" stands for additional parameters that are "outputed" when the function 
call returns. 
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oiciur\ 


BD_ADDR 


in 


48 bit 


48 bit address of the remote 
device 


ConnectionHandle'* 


in 


uint16 


connection handle (on HCI 
level) associated with ACL link 
to remote device 


IncomingConnection 


in 


boolean 


true = incoming connection 
false = outgoing connection 



4.3 Interface to other multiplexing Protocols 

Other multiplexing protocols (e.g., RFCOMM) that need to make decisions on 
access to services query the security manager in a similar way as L2CAP. 
There is an additional registration procedure, which allows to set the access 
policy for connection to the multiplexing protocol itself. 

access := SEC_accessRequestMultiplexingProtocoI ( 
Protocolldentification, 
Channelldentification, 
BD_ADDR, 
ConnectionHandle 
IncomingConnection); 



Parameter 


I/O 


Type 


Content 


access 


ret 


boolean 


true = granted 
false = denied 


Protocolldentifi cation 


in 


uint32 


Number assigned to identify, 
which protocol has submitted 
the query 


Channelldentification 


in 


uint32 


Channel ID (or whatever is used 
in that protocol), where a 
decision of an access policy is 
based on; 

for RFCOMM: DLCI 


BD^ADDR 


in 


48 bit 


48 bit address of the remotes 
device 


ConnectionHandle^ 


in 


uintie 


connection handle (on HCI 
level) associated with ACL link 



The information Is redundant to the Bluetooth device address. However, the connection 
handle Is needed to initiate authentication and encryption via the HCI. 
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to remote device 


IncomingConnection 


in 


boolean 


true = incoming connection 
false = outgoing connection 



4.4 Interface to ESCE (e.g., Ul) 

The architecture includes user interaction for authorisation purposes. This 
includes access permission to services and setting up a trusted relationship to 
a remote device. 

access = SEC^authorisationRequest ( 
ServiceName, 
DeviceName, 

&FutureTrustedRelationship - false 

); 

The security manager calls the ESCE (e.g., the user interface); incoming 
parameters are the information submitted with the request, outgoing 
parameters hold the response. 



Parameter 


I/O 


Type 


Content 


ServiceName 


in 


String 


human readable name of the 
application (from registration 
of application) 


DeviceName 


in 


String 


human readable name of the 
device (retrieved using the 
name request or from internal 
database) 


Future TrustedRelationship 


out 


Boolean 


If this value is true, the remote 
device will be marked as 
trusted. 

Default value is false. 



If a PIN is requested by the security manager, the following call to the ESCE 
can be used. The PIN entry can also be requested directly from the link 
manager (then the security manager requests authentication, and the link 
manager performs the necessary actions if no valid link is available. 

SEC_PinRequest ( 

^ See footnote in previous section. 
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BD_ADDR, 

Name, 

PIN 

): 



Parameter 


I/O 


Type 


Content 


BD_ADDR 


in 


48 Bit 


48 bit address of the remote 
device 


Name 


in 


String 


Bluetooth device name 
(human readable name) 


PIN 


out 


String 


Bitfield, length < 16 bytes 



In case the the ESCE wants the security manager to create a trusted 
relationship outside of other procedures, a simple command may be used: 



SEC_createTrustedRelationship ( 
BD_ADDR 

); 

The ESCE (e.g., user interface) calls the security manager. 



Parameter 


I/O 


Type 


Content 


BD_ADDR 


in 


48 bit 


48 bit address of the remote 
device 



4.5 Registration Procedures 

There are certain registration procedures necessary: 

- services with their security level and protocol stack information 

- multiplexing protocols above L2CAP 

This registration can be done by the entity that is responsible for setting the 
path in the BT protocol stack. It is implementation-dependent, which entity 
does the registration. Without registration the default settings apply. 

SEC_registerApplication ( 
Name, 

SecurityLevei 
PSM, 

Protocolldentification, 
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Channelldentification 

): 



Parameter 


I/O 


Type 


Content 


Name 


in 


string 


human readable name of the 
application (intended for user 
queries) 


SecurityLevel 


in 


uint16 


Bit 0-2 incoming connection: 

bit 0 = authorisation required 
bit 1 = authentication required 
bit 2 = encryption required 

Bit 3-5 outgoing connection: 

bit 3 = authorisation required 
bit 4 = authentication required 
bit 5 = encryption required 

Bit 6 = reception of 
connectionless packets allowed 


PSM 


in 


uint16 


PSM value used at L2CAP level 


Protocolldentification 


in 


uint32 


Number assigned to identify, 
which protocol has to make the 
decision for access. 

Zero = decision at L2CAP 


Channelldentification 


in 


uint32 


Channel ID (or other appropriate 
multiplexing identifier), where a 
decision of an access policy is 
based on; 

for RFCOMM: DLCI 

In case of Protocolldentification 
=0, this value has to be ignored. 



SEC_registerMultiplexingProtocol ( 
Protocolldentification 
LowerProtocol, 
LowerChannel, 
Security Level 

); 



Parameter 


I/O 


Type 


Content 


Protocolldentification 


in 


uint32 


Number assigned to identify, 
which protocol is registered 
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LowerProtocol 


in 


uint32 


Protocolldentification of tlie next 
lower protocol 


LowerChannel 


in 


uint32 


Channelldentification used at 
the lower layer 


Security Level 


in 


uint16 


Bit 0-2 incoming connection: 

bit 0 = authorisation required 
bit 1 = authentication required 
bit 2 = encryption required 

Bit 3—5 outaoina connection* 

bit 3 = authorisation required 
bit 4 = authentication required 
bit 5 = encryption required 

Bit 6 = reception of 
connectionless packets allowed 



4.6 Interface to HCI / Link Manager 

4.6. 1. 1 Authentication request 

For requesting an authentication of a remote device, the 
HCI_Authentication_Requested command and as an answer the 
Authentication Complete event are used which are shown below. For further 
details please refer to 4.5.1 5 and 5.2.6 of [6] 



Command 


OCF 


Command Parameters 


Return Parameters 


HCI_Authentication_ 
Requested 


0x001 1 


Connection_Handle 





Event 


Event 
Code 


Event Parameters 


Authentication Complete 


0x06 


Status, 
Connection Handle 



4.6. 1.2 Encryption control 

For encryption control, the HCLSet_Connection_Encryption command and as 
an answer the Encryption Change event are used to enable and disable the 
link level encryption. For further details please refer to 4.5.16 and 5.2.8 of [6]. 
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Command 


OCF 


Command Parameters 


Return Parameters 


HCI_Set_ 
Connection_ 
Encryption 


0x0013 


Connection_Handle, 
Encryption_ Enable 







Eyerit 
Code 


Event Parameters 


Encryption Change 


0x08 


Status, 
Connection_Handle, 
Encryption_Enable 



4.6.1.3 Name request to remote device 

For a name request to a remote device, the HCI_Remote_Name_Request 
command and as an answer the Remote Name Request Complete event are 
used which are shown below. For further details please refer to 4.5.19 and 
5.2.7 of [6]. 



GtiirTimahcl 


OCR 


Commahd Param 


Return Parameters 


HCLRemote_Name_ 
Request 


0x0019 


BD_ADDR, 
Page_Scan_Repetition_ 
Mode, 
Page_Scan_Mode, 
Clock Offset 







Event 
Code 


Event Parameters 


Remote Name Request Complete 


0x07 


Status, 
BD_ADDR, 
Remote Name 



4.6. 1.4 Set encryption policy at link level 

The general encryption policy at link level can be set by the 
HCI_Write_Encryption_Mode command which will be answered by the 
Command Complete event, both shown below. The Encryption Mode 
parameter controls if the Bluetooth radio will require encryption at link level for 
each connection with other Bluetooth radios. For further details please refer to 
4.7.25 and 5.2.14 of [6]. " 
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Command 


OCF 


Command Parameters 


Return Parameters 


HCI_Write_ Encryption 
Mode 


0x0022 


Encryption_ Mode 


Status 



; Event/ ^'^r:; ^^ ■ 


Event 
Code 


Event Parameters 


Command Complete 


OxOE 


N u m_H C l_Co m ma n d_P a ckets , 
Command_Opcode, 
Return Parameters 



4.6.1.5 Set authentication policy at link level 

The general authentication policy at link level can be set the 
HCI_Write_Authentication_Enable command which is shown below. The 
Authentication_Enable parameter controls if the Bluetooth radio will require 
authentication at link level for each connection with other Bluetooth radios. As 
for the HCLWrite_Encryption_Mode answer, the Command Complete event is 
used. For further details please refer to 4.7.23 and 5.2.14 of [6]. 



Command 


OCF 


Command Parameters 


Return Parameters 


HCLWrite_ 
Authentication Enable 


0x0020 


Authentication_Enable 


Status 
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THE IMMINENT MARKET EXPLOSION OF BLUETOOTH 
WIRELESS INTERFACES ON PRODUCTS SIGNALS AN RF 
MEASUREMENT FIRST FOR MANY TEST ENGINEERS. 

On your marks for 
testing Bluetooth 



THE Bluetooth wireless standard is coming 
into its own, and hundreds of millions of Blue- 
tooth-enabled products will ship by the end of 
2002. The Bluetooth technology will be self-con- 
tained within many products; for others, it will be an 
addition in the form of a PC Card that plugs into a 
mobile device or a dongle that plugs into a desktop 
system s RS-232 or parallel-printer port. As Blue- 
tooth becomes ubiquitous, you 11 find yourself hav- 
ing to test Bluetooth devices at the protocol-stack 
and RF levels. 

A complete Bluetooth module comprises a radio 
transceiver, a baseband-link controller, and a link 
manager (Figure 1). The baseband-link controller 
connects the radio hardware to the baseband- pro- 
cessing and physical protocol layer. The link man- 
ager performs high-level protocol activities such as 
link setup, authentication, and configuration. Ap- 
plication-layer software sits above the link manager. 

A Bluetooth implementation can operate as a sin- 
gle-chip (integrating radio and protocol stack) or 
multi-chip (separate radio and protocol ICs) design. 
Cellular- phone manufacturers may wish to combine 
the Bluetooth baseband function in the same device 
as the GSM (Global Standard for Mobile Commu- 
nication) baseband function and, therefore, will 
want a separate Bluetooth radio. A digi- 
tal camera manufacturer is more likely to 



under test (Figure 2). For diese tests, the test system 
must be able to support the Bluetooth protocol to 
make the link. Consequently, you can expect instru- 
ment vendors to develop new test instruments sim- 
ilar to the integrated radio test sets for digital cellu- 
lar radio. 

For protocol tests, you can use protocol sniffers 
that monitor and display data moving between Blue- 
tooth devices. You can also use products such as the 
EBDK (Ericsson Bluetooth Development Kit) (Ref- 
erence 1). Ericsson will soon release a version of the 
EBDK, known as a Blue Unit, that will include soft- 
ware for use during early qualification testing. Even- 
tually, some companies should develop complete 
reference test systems. 

A profile is the application level protocol that 
makes a device perform its functions as the user ex- 
pects. All Bluetooth devices that claim to offer a giv- 
en functionality must use the appropriate profile 
from the Bluetooth specification. This requirement 
ensures interoperability between common devices 
from multiple vendors. 

For example, the LAN access profile defines a data 
connection between a DT (data terminal) and a LAP 



Figure I 



select a single-chip design to simplify assembly. 

RF, PROTOCOL, AND PROFILES 

Three aspects of a Bluetooth module need testing: 
RF, protocol, and profiles. You can perform many of 
the RF rneasurements with standard test instru- 
ments such as spectrum analyzers with vector de- 
modulation, transmitter analyzers, power meters, 
digital-signal generators, and BERTs (bit-error- rate 
testers). 

Some of the measurements, however, require the 
radio to form a standard Bluetooth radio-link con- 
nection with the test instrument and the test in- 
strument to have some control over the equipment 

This article appeared in Test & Measurement World/ 
September 2000. 
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A complete Bluetooth module comprises a radio transceiver, 
a baseband-link controller, and a link manager. 
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(LAN access point). The profile defines 
the following services and connection 
states for the application layer: initializa- 
tion of LAN access service, shutdown of 
LAN access service, establishment of LAN 
connection, loss of LAN connection, and 
disconnection of LAN connection. 

Until a reference test system is avail- 
able, early Bluetooth profile testing will 
require product-to-product interoper- 
ability testing. To facilitate this, a series of 
"Unplugfests" have been arranged by the 
Bluetooth Special Interest Group 
(www.bluetoothxom). At these meet- 
ings, companies with functional prod- 
ucts can test product interoperability 
against products from other suppliers. 

RF AND SINGLE-CHIP MEASUREMENTS 

The Bluetooth radio specification out- 
lines the performance requirements for 
the radio and the test to confirm confor- 
mance (Table 1). To measure the per- 
formance of a Bluetooth module, the test 
instrumentation must be able to estab- 
lish a Bluetooth link with the EUT 
(equipment under test). It can then put 
the EUT into test mode. Test mode is a 
mandatory feature of a Bluetooth mod- 
iile in which the EUT can enter a loop- 
back mode or can disable fi*equency hop- 
ping for making BER measurements, for 
example. A Bluetooth test system should 
also be able to disable hopping, set spe- 
cific frequencies for tests, and control the 
transmit power level. 

During design and development, you 11 
want to test the radio in isolation from 
the protocol stack that controls it. In 
these cases, you need to control the ra- 
dio so you can set frequencies and levels 
to make raw transceiver measurements. 



Figure 2 
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You can then feed the 
radio output 
directiy into a 
spectrum analyzer 
with vector signal 
analysis or into a 
transmitter analyzer 
and power meter to 
make the measure- 
ments (Figure 3). 
The measurements 
you can make will 
vary according to the 
control that the ra- 
dio IC manufacturer 
provides over the IC 
connectors. The radio will have inputs 
controlling data in and out, Tx on, clocks, 
and supply voltage. Without a protocol 
stack, the radio may not function at all. 

Many radio designs permit you to feed 
PRBS (pseudo-random bit sequences) 
into the transmitter modulator and use 
manufacturer-specific control lines to 
force the radio to transmit continuously 
at one frequency. Doing so enables you to 
make frequency, power, and modulation 
measurements as well as output spec- 
trum measurements. As an alternative 
method to radio IC testing, you can build 
a test jig that holds the radio IC and has 
a protocol stack built onto it. This 
method allows for comprehensive testing 
and simulates the integrated module ap- 
proach outlined below. 

There is no standard for the interface 
between a protocol stack and a radio, typ- 
ically known as the radio interface. You 
must use a test fixture to hold the radio IC 
and provide it with some baseband con- 
trol to give Bluetooth functionality. This 
arrangement lets you test radio ICs with 
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Some Biuetooth tests require the test instrument to support the Blue- 
tooth protocol to form a standard Bluetooth radio-link connection. 



a Bluetooth link and baseband control. 

The connection between the radio and 
the test instrument vary depending upon 
the Bluetooth device implementation. 
Some radios or integrated modules have 
printed antennas as part of the design. In 
this case, you may only be able to make a 
connection over the air to an antenna on 
the test instrument input. If you use this 
approach, then you must characterize the 
path loss for each of the 79 Bluetooth fre- 
quencies. If the radio IC has an RF out- 
put connector, a direct connection to the 
test instrument simplifies calibrated 
power and sensitivity measurements. 
Even if you use a direct connection, 
though, you should measure and correct 
for the path loss at each frequency. 

TESTING OEM BLUETOOTH PRODUCTS 

OEMs buying commercial Bluetooth 
chip sets still need to test. Inevitably, 
packaging can influence the performance 
of a finished product because of the an- 
tenna s position as well as other internal 
electronics. In a mobile phone, the other 



HOW TO QUALIFY PRODUCTS WITH BLUETOOTH INTERFACES 



No product may be sold as 
"Bluetooth enabled" without first 
demonstrating compliance with 
the Bluetooth specification. You 
can refer to the rules laid out in 
the Bluetooth Qualification Pro- 
gram when you check compli- 
ance. Qualification is essential for 
ensuring that consumers have a 
good experience with Bluetooth- 
branded products. You must 
make sure that interoperability 
between products supplied by 



different manufacturers is guar- 
anteed. 

To obtain qualification, a man- 
ufacturer must first become a 
Bluetooth member by signing 
the adopters agreement Two ad- 
ditional bodies help qualify a 
product: a BQTF (Bluetooth 
Qualification Test Facility) and a 
BQB (Bluetooth Qualification 
Body). 

A BQTF is an accredited or- 
ganization with the skills and 



equipment to test a product 
based on the Bluetooth specifi- 
cation. A BQTF may choose not 
to offer qualification for every as- 
pect of the Bluetooth standard. 
For example, many profiles are 
limited to a few specific applica- 
tions, and some aspects of the 
Bluetooth specification are op- 
tional. The BQTF performs meas- 
urements on behalf of the man- 
ufacturer on the appropriate 
radio, protocol, and profiles for 



the equipment under test. The 
BQTF prepares a test report that 
forms part of a compliance fold- 
er that is submitted to the BQB. 

The role of the BQB is to re- 
view all submitted documenta- 
tion and ensure that all the ap- 
propriate tests have been 
performed and passed satisfarto- 
rily. If all is well, the product is 
listed as Bluetooth qualified and 
may be sold as Bluetooth en- 
abled. 
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electronics will, by definition, include an In the OEM production environment, 

interfering radio transceiver. Similarly, the tests have to validate performance in 

PCs have high-speed clocks or noisy bus- the shortest possible time. Production 

es that can degrade module sensitivity. engineers need to select the subset of the 



conformance test specifications that are 
appropriate for their products* require- 
ments. 

To confirm that the device will operate 
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over the Bluetooth specification's 10-m 
range, engineers will still need to meas- 
ure sensitivity and power levels. The con- 
formance specification requires engi- 
neers to measure receiver sensitivity as a 
BER of more than 1 ,600,000 bits at three 
frequencies. This test alone would take at 
least 25 sec using standard single-slot 
DHl packets and so, in practice, the test 
will measure fewer bits even at a 
reduced number of frequencies. 

In addition to RF measurements, 
OEMs should perform a functional test. 
In the case of a Bluetooth-enabled digi- 
tal camera, for example, functional test- 
ing can include sending an instruction 
over the Bluetooth interface to activate a 
shutter release with flash. Engineers 
would need to create this command at a 
high level in the protocol stack (typical- 
ly the application level), and the test 
equipment would need to package the 
command into the Bluetooth format. 
Validating the cameras response to a 
high-level command would give the 
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In devetopment you make raw transceiver measurements of a Bluetooth radio IC in isolation from 
the protocol stack. 



manufacturer confidence that the inter- 
face was ftinctioning correctiy, although 
it is not necessarily a guarantee of robust 
performance. □ 

Reference 

1 . Available from Symbionics. www. 
symbionics.co.uk/solutions/bluetooth/ 
Bluetoothkit.shtml. 



Author biography 
Angus Robinson is product marketing 
manager for RF and microwave test in- 
struments with Anritsu, Stevenage^ UK. 
He joined Anritsu in 1998 having previ- 
ously worked with Marconi Instruments 
(now fFR) after receiving a Bachelor of 
Engineering degree in electronics at Liver- 
pool University in 1982. 



BACKGROUND TO BLUETOOTH 



As a standard for wireless communication 
between multiple devices, Bluetooth sup- 
ports voice and data. In 1994, Ericsson began 
to develop the standard at its Lund site in 
Sweden (Table A). The project was initially 
called MC Link (multicommunicator link). In 
1997, Ericsson approached other companies 
with a mutual interest in defining an open 
standard for a wireless link. In February 1998, 



five promoters-Ericsson, IBM, Intel, Nokia, 
and Toshiba-formed the SIG (Special Inter- 
est Group) to promote the standard, which 
they renamed Bluetooth. 

The Bluetooth SIG announced the stan- 
dard on May 20, 1998. Two years later, more 
than 1800 companies had joined the consor- 
tium as adopters of the technology. The con- 
sortium's objective is to create a de facto 
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short-range wireless communication standard 
that all companies could use. In the autumn 
of 1999, the promoter group was expanded 
to nine companies, adding 3Com, Lucent 
Technologies, Microsoft, and Motorola. Al- 
though today the Bluetooth SIG standard is 
"owned" by the promoter group, it is expect- 
ed that the standard will become an IEEE 
standard (802.15) this year and remain fun- 
damentally the same. 

Bluetooth offers wireless communication 
between one or more devices over a 10-m 
range with a maximum gross data rate of 721 
kbps in the unlicensed 2.4-GHz ISM band. 
The purpose of the technology is to offer a 
low-cost, simple-to-use alternative to wired 
connections. As such, the potential user base 
is large and varied. 

The first adopters of Bluetooth are expect- 
ed to be mobile- phone manufacturers with 
wireless headsets. Mobile phones could also 
interface with a Bluetooth-enabled PCs to ex- 
change files or e-mail. A PC could have a 
wireless mouse and keyboard, and office 
printers could become Bluetooth enabled so 
that wireless printing is possible in any loca- 
tion. Other early adopters of the technology 
include PDAs (personal digital assistants), 
LAN access points, digital cameras, and secu- 
rity-access cards. 
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Internet world is replete with buzzwords, trends, and rumors about the latest technologies coming to 
the fore. Ask anyone these days what the new darling of the Internet is, and they will tell you 
without a doubt that it's wireless technologies. Online journals, newsgroups, discussion forums, and 
print publications concerning the Internet are engaged in a furious exchange of opinions in which 
the pros and cons of various wireless data transmission protocols are alternately praised and reviled. 
One such protocol, simultaneously adored and despised, is Bluetooth ( http://www.bluetooth.com ). 

According to Cahners In-Stat Group r http://vyww.instat.com ) in its July 2000 report, "Bluetooth 
2000: To Enable the Star Trek Generation," the manufacture of Bluetooth-enabled equipment will 
exceed one billion units by 2005, and the market will be worth some $5 billion. Frost & Sullivan 
( http://www.frost.com ) is equally optimistic. It forecasts global shipments of Bluetooth-enabled 
products to reach over 1 1 million units in 2001 and predicts $2.5 billion in revenues. 

The name itself is enough to start you wondering. When discussing the dry topic of data 
transmission protocols, we are used to throwing around terms such as TCP/IP, RIP, or PPP. 
Whether or not we can decipher the acronym, the terms have been used so often that most people 
have some idea of what we are talking about. But mention Bluetooth to the uninitiated and you're 
likely to be met with puzzled looks. 

A BIT ABOUT BLUETOOTH 

Bluetooth, named after the 10th century Viking king Harald Bluetooth, is a de facto data 
transmission standard developed by Ericsson and backed by a host of other technology companies 
that make up the Bluetooth Special Interest Group (including Ericsson, Intel, Puma Technology, 
Microsoft, Motorola, Nokia, 3Com, Lucent Technologies, and Toshiba). Bluetooth employs the 
unlicensed radio frequency (RF) portion of the electromagnetic spectrum in the 2.4-2.4835 gHz 
range. More simply, Bluetooth is a low-power, spread-spectrum technology that uses frequency- 
hopping to ensure speedy, short-range wireless data transfer of up to 720 kbps at a range of 30-100 
feet. Intended as a replacement for the short-range data cable, Bluetooth's original conception was 
as a wireless peripheral interface, linking print- ers, monitors, keyboards, and other peripheral 
devices to the CPU. However, the potential for the technology is much greater, offering the ability 
to link devices of different types, forming instant workgroups across multiple platforms in a 
seamless fashion. So how does Bluetooth work? 

The Bluetooth standard is a complex conglomeration of protocols arranged in a protocol stack, 
which, when diagramed, somewhat resembles a Dagwood-style sandwich. To put it more simply, 
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Bluetooth relies upon radio frequencies to transmit data, providing a universal bridge between 
devices on a network, or betAveen devices from the outside and an existing network using a 
combination of circuit and packet-switching technologies. Bridges have the ability to link together 
different types of networks because a bridge delivers data based upon the MAC (Medium Access 
Control) address that is hard-coded into the network hardware by the factory that manufactures it, 
and it is unique for every device. This differs from other network devices, such as routers, that 
deliver network data based upon routable protocols such as TCP/IP. Because bridges operate at a 
lower level of the protocol stack, standards like Bluetooth can link unlike devices within a local 
network. The data is, like all network traffic, divided into packets. However, because Bluetooth is 
designed to work in the RF enviromnent-a very noisy portion of the electromagnetic spectrum-it 
employs the use of shorter packets for transmission, and combines this with fast frequency-hopping 
to ensure a fairly robust connection. 

When a message is sent over a Bluetooth connection, each packet is transmitted on a different 
frequency within a range of 2.4-2.4835 gHz. After the first packet is transmitted, the Bluetooth 
controller hops to a different frequency before sending out the next packet. The determination of 
which frequency within the given range will be used to start packet transmission is semi-random 
and is controlled by the Bluetooth Radio portion of the protocol stack. This frequency remains fixed 
for the duration of each packet. However, once the initial transmission frequency is chosen for the 
first packet, the remaining frequencies are cycled through for each subsequent packet in a 
determined fashion. This is known as the phase. 

BLUETOOTH IS SOCIAL 

When two or more Bluetooth-enabled devices are within range of each other, they automatically 
start communicating. Each Bluetooth-enabled device periodically broadcasts an inquiry message to 
see if there are any other Bluetooth devices in the area. If there is a response from another device, 
the originator of the inquiry message becomes the Master unit and the responder becomes the Slave. 
This arrangement is completely dependent upon which device is the first to send the inquiry 
message out when it comes within range, and does not resemble a client/server relationship. After 
this initial contact, the Master sends the slave(s) information about how they will communicate (i.e. 
the initial frequency and phase). These ad hoc networks are called Piconets. Collections of Piconets 
form Scattemets. Bluetooth supports point-to-point as well as point-to-multipoint links depending 
upon the number of devices within communication range. In each case, the connections are peer-to- 
peer. 

Bluetooth can send data along four different channels simultaneously. Included is an asynchronous 
data channel (meaning packets are not sent out in pre-selected timeslots governed by the processor 
clock, but rather whenever there's an opportunity), and up to three simultaneous synchronous voice 
channels, or a combination channel, simultaneously supporting asynchronous data and synchronous 
voice. Each synchronous voice channel can support transfer rates of 64 kbps, and the asynchronous 
channel can support a bi-directional (two-way) asymmetric link of up to 721 kbps in either direction 
while permitting 57.6 kbps in the return direction. 

So what does all of this have to do with libraries and information professionals? A lot, if the push to 
promote the standard is successftil. 

WILL LIBRARIES DEVELOP A TASTE FOR BLUETOOTH? 

Imagine an environment where users enter the library with their personal digital assistants (PDAs) 
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and are instantly connected to the network. They can pull up their records, search proprietary 
databases and the Web, check email, download information, and even check out materials from the 
stacks without ever having to stop at the checkout desk. All of these things are theoretically 
possible using the Bluetooth standard. Bluetooth-enabled networks have the potential to allow 
libraries to offer the kind of value-added services often held up as the holy grail of mission 
statements. 

In Ken Vamum*s insightful article entitled "Information at Your Fingertips: Porting Library 
Services to the PDA," appearing in the September/ October 2000 issue of ONLINE, he illustrates 
how Ford Motor Company's corporate library is taking the initiative in porting library services to 
handheld devices, such as the PDA. The article demonstrates precisely how the engaged and aware 
information professional is finding new avenues for reaching out to users. Vamum explains how the 
library has effectively employed a third-party software package to translate Web pages into PDA- 
friendly files that users can download and take along with them on trips away from the office. This 
technology allows users to view documents, check and respond to email messages, and even fill out 
online forms. The drawback, of course, is that the user must return to the office and interface the 
PDA with a PC in order to synchronize the devices and actually transmit the email, form, etc. The 
PDA itself is not connected online and does not allow for real-time operation. 

Now, take that scenario and replace the old PDA with a new Bluetooth-enabled PDA. Then suppose 
traveling users find themselves at a hotel, airport, or library with a Bluetooth-enabled network 
connected to the Internet. Our users can now not only respond to email messages, but send them as 
well. They can conduct research and download updated documents. They can even use their PDAs 
to make phone calls. In short, the user has been given the type of information access that would 
have been unimaginable just a few years ago. 

BLUETOOTH IN TRADITIONAL SETTINGS 

Even the more traditional academic or public libraries could reap the benefits of a Bluetooth- 
enabled network. Librarians at the reference desk assisting patrons in their research could directly 
beam the results to the patron's PDA, avoiding the cost of printing out the documents. Patrons with 
Bluetooth enabled devices connected to the library network could work together in ad hoc user 
groups, sharing information electronically. Library instructional sessions could be greatly facilitated 
by turning a patron^s personal device into an instant workstation, eliminating the need for the library 
to purchase and maintain expensive computer labs. Network printers could be placed throughout the 
library for those who wish to obtain printouts without the restrictions that come with traditional 
network cables or the line-of-sight problems that accompany devices using infrared. A prototype 
description of Swedish rail traffic in the ftiture ( http ://www. swedetrack.se/usblue2.htm ) proposes 
placing Bluetooth units at public libraries close to train stations to be used as passenger interfaces. 

LEXIS-NEXIS has teamed up with a primary developer of the Bluetooth Standard and member of 
the Bluetooth SIG, Red-M, a subsidiary of the Dutch company Madge Networks, to launch m-news. 
With content fi-om LEXIS-NEXIS, m-news will provide subscribers with email updates and 
hypertext links to stories located on the Red-M Web site that detail Bluetooth industry 
developments. Registration is required but the service is free 
( http://www.redm.corn/aboutred/newsroom/content.asp?Article=21 ). 

And if all of that sounds too good to be true, you may be right. 

BLUETOOTH MAY HAVE PROBLEMS AT ITS ROOT 
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The potential for Bluetooth is enormous, but its road to acceptance has been rife with criticisms and 
obstacles, some of which are substantial indeed. First there is the issue of cost. The original model 
developed by the Bluetooth SIG in 1998 called for a figure of $5 to integrate Bluetooth radio 
transceivers and link-level controllers into hand-held devices. The reality has been more in the 
range of $50 for the components, or slightly less if purchased in large quantities. And this is the 
price paid by the original equipment manufacturers (OEMs). Undoubtedly, by the time the device 
reaches the market, the price will be considerably higher. This has effectively put it out of the reach 
of most consumers. The inflated prices, however, are not the result of corporate greed, but more the 
unpredictable consequence of the technical difficulty of producing the chips and the resulting size 
of the chip being somewhat larger than anticipated. 

Another significant problem is that of interference. As Joe Wilcox, staff writer for CNET 
News.com notes in his September 15 article, "As Bluetooth Nibbles, Competition 
Lurks" ( http://news.cnet.com/news/0- 1003-2Q0-27847Q2.html \ the issue of frequency interference 
could potentially harm Bluetooth a great deal. Because Bluetooth uses the unlicensed radio portion 
of the electromagnetic spectrum, transmissions in that band must compete with industrial 
microwave ovens, stadium lights, garage door openers, cordless telephones, and virtually any 
wireless household appliance, even baby monitors. More detrimental to the long-term health of the 
Bluetooth standard, however, is its interference v^th two other wireless standards using the same 
2.4 gHz band that are older and more established: that of the 802.1 IB and the HomeRF. While 
these standards lack the catchy name and media hype that Bluetooth currently enjoys, 802.1 IB 
allows portable electronic devices to connect to an existing network at distances up to 300 feet 
rather than the paltry 100 feet that limits Bluetooth. Additionally, HomeRF recently won a ruling 
from the FCC that allows it to expand its bandwidth to 5mHz (up from ImHz), effectively 
increasing transmission speeds to 10 Mbps. While there is room for these standards to operate in a 
complementary fashion within a wireless network environment, another challenge rears its head: 
compatibility. 

The bickering over who has control over various portions of the spectrum gets even uglier when 
dealing with the unlicensed portion that Bluetooth and other standards exploit. There is little that 
the FCC can do to regulate this area and still preserve the integrity of maintaining an open portion 
of bandwidth. To get around some of the interference problems, both HomeRF and Bluetooth use 
frequency-hopping. In contrast, the 802.1 IB standard has developed around a direct-sequence 
model in which only one frequency is used for transmission. The use of these two different methods 
introduces incompatibility between devices. A frequency-hopping Bluetooth device and a direct- 
sequence 802.1 IB device would not be able to communicate with each other. 

Add to that the security problems inherent in the Bluetooth standard, and the outlook appears grim. 
There is a security layer within the specification for Bluetooth, but by all accounts, it is easily 
misunderstood and prone to confusion. As Wilcox reports, an analyst with Gartner, a leading 
Internet industry consulting firm states, "Bluetooth is a disaster waiting to happenEthe specs cover 
(security), but unless you know what you*re doing, it's possible to implement the spec in such a 
fashion (that) you aren't doing anything worthwhile." 

IT TAKES TWO TO TANGO 

The rollout of Bluetooth-enabled devices has experienced many delays as a result of some of these 
issues. When the Bluetooth SIG was first formed, the company fully expected to see widespread 
implementation by Christmas of 2000. Unfortunately, it has been only recently that Bluetooth- 
equipped devices have begun to trickle out of the development labs and into the hands of 
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consumers. Even so, there are not enough Bluetooth products around to make it a worthwhile 
investment. One Bluetooth device is no good-you really need at least two to play. Yet it is 
important to bear in mind that these problems are not insurmountable. Dozens of companies have 
significant resources sunk into the development of Bluetooth. To abandon it would represent a 
tremendous loss of time and money. While the future of the technology is by no means secure 
(there are a lot of kinks to work out), you can rest assured that much effort will go into its continued 
development and promotion. We'll see within the next few years if Bluetooth will sink its teeth into 
the information industry, or bite itself in the butt. 



Harald Bluetooth 

Harald Bluetooth, son of Denmark^s first king, Gorm the Old, from whom the present Danish 
queen, Margarethe II,, traces direct descent, did not have blue teeth. Instead, the name refers to a 
great man with a dark complexion. The Danish word for blue, bla, also meant dark and the words 
for man, mand, and tooth, tand, sound much the same. Harald Bluetooth is credited with 
Christianizing Denmark, Norway, and parts of Sweden and with uniting the countries into one 
kingdom. At the time of his rule, somewhere between 940 and 980 AD, southern Sweden was part 
of Denmark. In southern Sweden is the city of Lund, which is where Ericsson developed the 
Bluetooth technology. According to Ericsson in its discussion of Harald Bluetooth 
( http://bluetooth.ericsson.se/bl uetoothf/beginnersg/default.asp?page=2 ). "One of his skills was to 
make people talk to each other....," hence the choice of Bluetooth to name this communications 
standard. If you're ever in Jelling, Denmark, you can view the rune stone Harald Bluetooth raised in 
honor of his parents. There's another, vastly newer, rune stone dedicated to Bluetooth himself. It's 
outside Ericsson's Mobile Communications office in Lund. 
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Abstract 

Bluetooth is an emerging technology for coQstnicting ad- 
hoc wireless Personal Area Networks (WPANs). In this paper 
we analyze an innovative scheduling algorithm for 
asynchronous data traffic specifically tailored to the 
Bluetooth characteristic. This algorithm, named EEficient 
Double-Cycle (EDC), dynamically adapts the poUtng 
fi^ueacy to the traffic conditions, fi^ considering a 
scenario where a Bluetoo^ master is used as wireless access 
point to the Internet, we show that our EDC scheduler 
significantly enhances the system performance widi regard 
to a Round Robin <RR) scheduler. 

Keywords 

Bluetooth. TCP, Scheduling, Medium Access Control 
(MAC), Polling, Automatic Repeat Request (ARQ). 

1. Introduction 

The technologies for WPANs, as the emerging Bluetooth 
technology, offer a wide space for innovative solutions and 
applications that could bring to a radical change in everyday 
life. In particular, the Bluetooth technology is much more 
than a wireless connection for a nomadic access to the 
Internet or for cable replacement, but it wants to be an 
enabling technology for the global mobility of devices and 
services [2], [4]. 

Before Bluetooth applications can be deployed, it is 
necessary a considerable effort from the research community 
to resolve the technical issues specific to this technology. In 
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particular, the strong need for low-cost, low-power and low- 
complexity devices has lead the Bluetooth standardization 
fonmi to adopt a centralized Time Division Duplex (JDD) 
access scheme as the MAC protocol for the channel access. In 
a Bluetooth network, named as piconet^ one station has the 
role of master and all other Bluetooth stations are slaves. Up 
to seven slaves can participate to &e piconet 
communications. The master decides which slave is the one 
that can access the channel. More precisely, a slave is 
authorized to deliver a single packet xa the master only if it 
has received a polling message firom the master. 

Hence the schediUing algorithm is a key component in a 
Bluetooth network, the standard documents initially 
proposes a Round Robin {RR) scheduler [1]. Previous works 
[6], [4] have shown that the RR algorithm may introduce 
bandwidth wastage. Therefore, efficient MAC scheduling 
algorithms need to be designed. The original contribution of 
this paper is the performance evaluation of an e^icient 
scheduling algorithm named Efficient Double-Cycle {JEDQ, 
considering Internet trafiQc. Oui algorithm tunes the polling 
order to the network traffic conditions to limit the channel - 
bandwidth wastage caused by the polling of empty stations. 

Johansson et aL have proposed a Fair Exhaustive 
Polling {FEF) [6]. Similarly to our algorithm, FEP tries to 
avoid the polling of inactive stations. Specifically, they 
define the meaning of active and inactive state for the staves, 
and introduce polling sub cycles where only the active 
slaves are polled in a round robin fashion. Our algorithm 
further extends this idea i) by separating the scheduling of 
the uplink and downlink transmissions, and ii) by adopting 
a truncated binary exponential-backoff algorithm to 
determine the amount of time an inactive slave is removed 
from the polling cycle. 

The design of a scheduler suitable for the Bluetooth 
MAC layer was also considered by Shorey el al. They have 
iwoposed several MAC scheduling algorithms [8], [9] where 
they distinguish the mas ter- slave pairs based on the state of 
the queues at the master and slaves. They assume that the 
information regarding tfie status of the queue at the slave is 
available in the master because it comes directly from the 
slaves, which appropriately set some bits in the MAC 
header. Once that different classes/priorities are assigned to 
each master^lave pair, various service policies can be 
devised. Our scheduling algorithm departs from this 
approach because it does not rely upon any information 
coming from staves. 

In [10] we have exhaustively studied the EDC behavior 
from the MAC layer standpoint Specifically, we have 
investigated several performance figures, as aggregate link 
utilization, MAC delays and power indexes, and we have 
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found that EDC always outperfonns RR. This analysis was a 
theoretical one, as we do not consider the real crafTtc and the 
impact of high-layer protocols cm the traffic spacing. Since 
one of the most interesting Bluetooth applications is 
expected to be the ubiquitous wireless access to Intemet* in 
this work we extend the previous analysis to a realistic case 
in which die impact of TCP flow-control mechanisms has 
been investigated. 

The performances of TCP over Bluetooth have been 
investigated by others. A preliminary analysis of TCP 
performance over Bluetooth is presented in [7], but this 
analysis is only related to the TCP Vegas that is rarely 
adopted in current TCP implementation. In [9] a more 
accurate analysis of TCP perfonnancea has been executed, 
but no insight is given on the impact of TCP parameters over 
the perfonnances of a connection delivered via a Bluetooth 
link. 

The results presented in the following indicate that EDC 
provides a significantly throughput improvement for the 
TCP connections, when compared with the RR scheduler. 
Particular attention has been devoted to the study of the role 
of the TCP Maximum Segment Size (MSS) over the 
throughput performance. We also Investigate the impact of 
channel errors over the TCP and the effectiveness of the ARQ 
scheme adopted in Bluetooth for error recovery. 

The paper is organized as follows. In Section 2 we 
briefly describes the Bluetooth MAC layer, with a particular 
attention to the channel access scheme. In Section 3 we give 
the specification of our scheduling algorithm. Then, Section 
4 presents a complete performance evaluation of the 
scheduling algorithm. Concluding remarks are summarized 
in Section 5. 

2, Overview of the Bluetooth MAC Protocol 

From a logical standpoint. Bluetooth belongs to the 
contention-finee token-based multi-access networks [4]. A 
Time Division Duplex (TDD) scheme of transmission is 
adopted. The channel is divided into time slots, each 625 i^s 
in length. The time slots are numbered according to the 
BluetooA clock of the master. The master can begin a new 
transmission in even numbered time slots. Odd numbered 
time slots are reserved for the beginning of slaves' 
transmissions. As stated before, the channel access is 
managed according to a polling scheme. The master decides 
which slave is the only one to have the access to the channel 
by sending to him a packet. The master packet may contain 
data or can simply be a polling packet When the slave 
receives a packet 3&om the roaster it is obliged to transmit in 
the next time slot, to acknowledge the master transmission. 
This implies that the scheduling decisions are always related 
to a couple of sUtions: the master and the slave that receives 
the master transmission. The slave packet can contain data or 
can simply be a NULL packet. 

There arc two types of physical links that can be 
established between Bluetooth devices: a Synchronous 
Connection-Oriented {SCO) link, and an Asynchronous 
ConnectionLess (ACL) link. The first type of physical link is 
a point-to-point, symmetric connection t>etween the master 
and a specific slave. It is used to deliver delay-sensitive 
traffic, mainly voice. The SCO link rate is 64 kbps and it is 
settled by reserving a couple of consecutive slots for master- 
to-slave transmission and immediate slave-to-mastcr 
response. For SCO links the master periodically polls the 
corresponding slave, instead the polling is asynchronous 
for ACL links. 

The SCO link can be considered as a circuit-switched 
connection between the master and the slave. The second 
kind of physical link, the ACL link, is a connection between 
the master arKi all staves participating to the picooet. and it 



can be considered as a packet-switched connection between 
the Bluetooth devices that supports point-to-multipoint 
transmissions from the master to the slaves. The ACL 
channel guarantees the reliable delivery of data: a fast 
Automatic Repeat Request {ARQ) scheme is adopted to 
assure data integrity. 

The MAC layer also accomplishes the Segmentation and 
Reassembly {SAR) procedure to improve the protocol 
efficiency by supporting a maximum transmission unit size 
(MTXf) larger that the ACL packet sizes. 

T able 1. ACL packets' maximum payload sizes (byt es) 
XWi DHj DHs DMj DMs DMs 
27 183 339 17 121 224 



It is worth pointing out that a tight constraint of Bluetooth 
technology is that ACL packets can cover? 1, 3 or 5 time 
slots. According to Bluetooth specification [1], die ACL 
packets are of two different groups, one denoted DMx and 
the other one denoted DHr. The former has a payload 
encoded with a rate 2/3 FEC and the latter hasn*t got a FEC 
encoding. The subscript x stands for the number of slots that 
arc necessary to transmit the packet. Table 1 reports the 
dififerent payload size of ACL packets. 

More details about the Bluetooth Mac protocol can be 
found in [1], [3]. 

3. Efficient Double Cycle Scheduling 
Algorithm for a Bluetooth Piconet 

The Efficient Double-Cycle {EDQ algorithm is based upon 
two main ideas: furst of all it is necessary to avoid NULL 
transmissions towards and fiom the slaves; furthermore the 
fairness typical of a Round Robin scheme should be 
preserved. These targets can be accomplished if the selection 
of the slave to be polled takes into consideration the master 
knowledge of traffic fiom and to the staves. In the rest of our 
discussion, we assume a system model where the master 
employs a separate queue for each slaves participating to 
piconet coramunications. It is worth pointing out that the 
master has a deterministic knowledge of the state of its local 
queues, i.e.. the queues containing the packets for the slaves. 
On the other direction (i.e., traffic firom the slaves), we only 
assume that the master has a probabilistic knowledge based 
on the feedback the master gets when polling the slaves. 
Therefore the master can only estimate the probability that a 
slave will send a NULL packet by exploiting the knowledge 
of the slave behavior in the previous polling cycles. As 
stated in the introduction, our goal is to defme an efficient 
scheduling algorithm that is not implementation dependent, 
namely, it does not require that all slaves are able to set 
specific header fields according to the particular scheduling 
algorithm adopted by the master. Hereafter, we indicate as 
uplink the link direction from slaves to master, and as 
downlink the link direction from master towards slaves. 

An additional problem to have a fair and efficient 
scheduling in Bluetooth is caused to the coupling between 
the transmission in uplink and downlink (i.e. a master to 
slave transmission implies also a polling of the slave and 
hence a, possibly NUm slave to master transmission). 
Therefore, it is not possible to remove a slave from the 
polling cycle without blocking at the same time the master 
transmissions towards this slave. To introduce a (partial) 
decoupling in the scheduling of the transmissions in uplink 
and downlink we introduce the idea of a double polling 
cycle: an uplink polling sub cychy hereafter called Cycteu^, 
and a downlink polling sub cycle^ hereafter called C^vlenty. 
During both of these cycles the master selects a subset of 
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slaves that are eligible for the polling. For the sake of 
brevity we wUl xcfier to the subset of eligible slaves selected 
during a Cydevp as E(UP)t and to the subset of eligible 
slaves selected during a Cycleow as E(DW). £(DW} is 
calculated considering only the state of master local queues, 
i.e. the ongoing traffic loads, whereas E(UP) is calculated 
considering only the estimated slaves' activity, i.e. the 
ingoing traffic loads. The distinction between polling rules 
for the downlink and the uplink permits to have a **/airness 
separation^*: in the downlink {uplink) sub cycle fairness is 
guaranteed only in the downlink (uplhik) direction. 

3*1 EDC specification 

A detailed EDC specification through pseudo-code can be 
found in [10]. Due to the space constraints we provide only 
on EDC specification through the natural language. 

The outcome of our polling algorithm is the next slave 
to be polled, also referred as nexi. Because there is a double 
cycle, we have a nextUp calculated during the Cyclevp, and a 
nextDw calculated during the Cycleow- A polling interval c, 
and a polling window are associated to each slave 5/. 
These variables are used to estimate the slave activity, and to 
implement a truncated binary exponential backoff 
mechanism to control the slaves polling frequency during a 
Cycleup.. Specifically, at die end of each Sk's packet 
reception, the master updates the polling interval and the 
polling window w> wiUi the following rules: 

\. \fSk sends a packet with a null payload, then its polling 
window wjr is doubled till a maximum value w^^x is 
reached. 

2. USk sends a packet with a not null payload, then Wk is 
settled to be 1. 

3. The polling interval Ck takes Ihc value. 

During a Cyclei^w all the 5, that belongs to E(DW) arc polled 
in a cyclic order (i.e. we adopt a Round Robin policy for the 
E(DW) set). After a slave has been polled it Is extracted from 
E(pW). Thoefore a Cycleow is completed only when E(DW) 
becomes empty. At the same way, during a Cycleup all the Si 
that belongs to E(UP) are polled in a cyclic order (i.e., we 
adopt a Round Robin policy for the E(UP) set). After a slave 
has been polled it is extracted from E(UP). Therefore a 
Cycleup is completed only when E(UP) becomes empty. We 
consider a polling cycle as completed if all the slaves that 
belong to both £(UP) and E(DW) have been polled. 

One of the most important tasks that is accomplished 
by the master at the beginning of each polling sub cycle is 
the update of E(UP) or E(DW) according to its knowledge 
about traffic loads. Specifically, E(UP} is constituted by all 
slaves Si that have Ci null at the beginning of a Cyclevp, 
Because E(UP) is updated before the beginning of each 
Cycleup^ if 5|has a c, equal to n, then n Cycleup must elapse 
before Si is polled during a Cycleup. On the other hand, 
E(DW) is constituted by all slaves Si to which the master has 
traffic to send at the beginning of a Cycleow, i.e., slaves 
corresponding to the not-empty master local queues. 

At the begitming of each new master transmission, 
according to the piconet timing, the tnaster executes the 
following actions: 

1. If the polling cycle is finished then EDC updates E(Dn) 
and a new polling cycle begins with a Cycleow^ 

2. If the polling cycle is not finished, EDC determines if 
the next transmission belongs to a Cycleow, Le.. E(D^ 
is not an empty set, otherwise EIX^ decreases the 
polling mterval variables, it updates EfUP) and a new 
Cycleup begins. 

It is worth noting that if at the beginning of a new polling 
cycle E(DW) is an empty set then EDC decreases the polling 
interval variables and a new Cycleup begins. This behavior 



corresponds to have a Cycleow with null duration. If E{IJP) 
and B(DW) are both empty sets EDC has no infoitoation to 
discriminate a slave from the others, then EDC applies a 
round robin polling lule till the master does not receive a 
data packet from a slave or at least one of its local queues is 
not empty. 

In the following section we present a complete 
simulative analysis of the EDC algorithm performances 
when it is used to schedule Internet traffic. By exploiting 
this analysis we demonstrate the perfomumce enhancement 
achieved by EDC, with respect to a round robin scheduling 
algorithm. Furthermore, we point out some specific issues 
related to the transport of TCP traffic over the Bluetooth link 
to give a better understanding of EDC behavior. 

4. Simulation Model and Performance 
Evaluation 

The network model simulated is a single piconet constituted 
by a master and up to seven slaves. A detailed description of 
the Bluetooth architecture and its protocol stack can be 
found in [1], [2]. For the sake of the following discussion we 
refer to Figure 1, where we report a simplified architecture of 
the system. 



TCP 


UDP 


IP 



L2CAP 



MAC 



PHY 



Internet 
Protocols 



Bluetooth 
Protocols 



Figure 1* Protocol stack 

The traffic sources generate TCP and UDP packets that are 
sent to the network hiycr, which adds its header (20 bytes). 
The L2CAP layer receives the data segments from the upper 
layers, it adds 4 bytes of L2CAP header and it queues the 
L2CAP packets in a buffer. The size of this buffer is chosen 
equal to 64 Kbytes that is the standard advertised window 
used in the TCP receiver. Since no more that an advertised 
wiiKlow of TCP traffic can be generated by a TCP sender, this 
buffer size guarantees that no buffer overflow losses are 
experimented by TCP traffic' It means that each TCP source 
see an infinite size buffer. This assumption permits to study 
the dynamic of TCP connections under an EDC scheduler 
without biasing effects due to the limited buffer size. 

Large L2CAP packets must be segmented into smaller 
Baseband packets before their transmission can take place. A 
new L2CAP packet caimot be served till all fragments 
(generated during the segmentation at the MAC layer) of the 
previous L2CAP packet have been successfully transmitted. 
The segmentation procedure is accomplished, just before the 
transmission, in such a way to maximize the amount of data 
conveyed by each baseband packet. In particular, the 
segmentation procedure executes the following steps: 

1 . Divide the L2CAP packet into an integer number of 5 
slot baseband packets. 

2. If the size x remaining to be fragmented is larger than 
the size of a 3 slot baseband packet, sent it as a 5 slot 
packet. 



' Let us remind that a stave establishes a single TCP 
connections with the master 
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3. If jf is larger tban the size of a ] slot baseband paciet 
but shorter than the size of a 3 slot baseband packet, 
send it as a 3 slot baseband packet. 

4. Otherwise, send jr as a I slot baseband packet. 

It would be possible to devise several SAR procedures (see 
[8], [9]), but this issue is left for future discussion. 

Figure 2 shows the network configuration and traffic 
parameters, twreafter refened to as scenario A, used in the 
experiments presented in tbe next section. The TCP sources 
are asymptotic comiectioDs, i.e., they have always a data 
packet ready to be transmitted (ftp-like traffic). TTw TCP 
version considered is the TCP-Reno, the roost worldwide 
adopted TCP implementation [5]. The UDP sources generate 
CfiR tra£Gc. In the figure the arrows indicate the direction of 
data packets in the connection slave-master. For each 
connection, the type of traffic (i.e., UDP or TCP), the time 
instant of beginning ad termination, and the bit rate (only 
for the UDP sources) are given. 

TCP traffic (ftp) 
^Steit='fl5 stop = 90* 



Master 




Stops 8Cs 
Slave? 

Figure 2. Traffic sources used ifi Scenario A 

We consider sources with different lime interval of activity 
to capture the dynamic behavior of the scheduling 
algorithia We also locate some sources in tbe master and 
other sources in the slaves to evaluate the fairness of 
scheduling algorithm between the uplink and downlink 
direction. Finally, we analyze the ability of dte schedulmg 
algorithm to adapt to asymmetric loads by considering 
different CBR rates. 

IXiring all the simulations carried out we have assumed 
WMAx equal to 32, and we have used ACL packets with no 
FEC encoding, i.e., only DHx packets (see Table 1). 

4.1 Numerical comparison between EDC 
and RR behavior 

In this section we consider and ideal channel with no errors, 
and we use a constant TCP packet size of 1024 bytes, a 
constant UDP packet size of 500 bytes and a TCP ACK size 
of 20 bytes. 

Figure 3 shows the throughput for the TCP connection 
of Slavel achieved in tbe scenario A with a master that 
adopts either the EDC algorithm or the Round Robin (RR) 
algohdmi. We observe that EDC guarantees a throi^put 
always significantly higher than the one achieved with a RR 
scheduler. 

In the time interval [0, ... 15sec] there is a single active TCP 
connection. During this time interval the throughput 
obtained with EDC is more than two times the one obtained 
with RR, due to the capacity of EDC to adapt the polling 
frequency to the sources' activity. The ripples observed after 
40 seconds are due to the starting of the UDP sources. Tbe 
same results have been obtained for the other TCP 
connections and they are not reported here. 
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Figure 3. TCP througbput of Slavel connection 
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Figure 4* UDP thronghpat of SUve4 and SlaveS 

Figure 4 shows the throughput of two CBR sources, the 
former located in . the master (curve labeled as Siave4) and 
the laaer located in a slave (curve labeled as SlaveS) . It is 
worth noting that in the link slave4-master all the UDP 
packets arc scheduled during flie downlink polling sub 
cycle t whereas in the link slaveS-master all the UDP packets 
are scheduled during the uplink polling sub cycle. However, 
the scheduler giv es a fair treatment to these flows. 
Furthermore, we observe that EDC increases the tfuroughput 
of TCP flows with respect to RR, but it also permits to 
guarantee a throughput for UDP flows equal to their rate, as 
RR. 

Figure 5 shows the throughput of the three TCP 
connections when they are contemporarily active. We 
observe that EDC behaves fairly with the TCP flows, as a RR 
scheduler does. We have proved the fairness of EDC when all 
the TCP data packets arc scheduled during Cycleow- In the 
following experiment we check if tbe different polling rules 
adopted during Cycle ow and Cycle up can have an impact over 
the TCP performances. 

Figure 6 shows the throughput of a TCP connection 
established between the slave2 and the master when the TCP 
sender is eitho^ located in the master (scenario A), or in the 
slave (scenario B). All the other sources behave exactly as in 
scenario A. This experiment shows that the TCP throughput 
slightly increases when the data packets flow is from the 
slave towards tbe master. This is due to the dLfferent 
frequency by which the scheduler polls slave2 during 
Cycleup in the two cases. 
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Figare 5. Fairness of EDC algorithm with respect tn TCP 
coDnectlon 
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Flgture 6. TCP tbronghpnt of Stave2 connection when 
reversing the connectioD direction 

Id scenario A, the slave2 queue contains the 
acknowledgement tra£&c. When the master sends a fragment 
of a TCP packet, it is highly probable that it receives a NULL 
packet from- the slave2 (the ACK cannot be generated by the 
TCP receiver till the TCP packet is completely received), 
therefore the polling interval for slave2 increases, and the 
slave2 will skip some of the following upUnk polling sub 
cycles. This behavior can reduce the rate by which ihc 
acknowledgement traffic is served, therefore also lowering 
the rate of TCP data Get us remind that the poUmg of one 
direction also means the polling of the other one). On the 
other hand, in scenario B the slave2 queue contains the data 
traffic, and it is highly probable to find a queued TCP packet 
(the TCP source is asymptotic), therefore no Cyclevp is 
skipped. Furthermore, as soon as the ACK for the slave2 is 
generated, the master will serve i1 in the first available 
CyclenWi with no additional delay. Obviously, this 
phenomenon is more evident when a few sources ore active, 
because the polling cycle is short. 

In conclusion, the results presented so far demonstrate 
that EDC significantly improves the throughput 
performance of TCP flows in a piconet, when compared to a 
RR scheduler. Furthermore, we have clarified that the 
decoupling of scheduler decisions related to the polling of 
the uplink and downlink can imply some issues when the 
traffic flows from a slave to the master and in the inverse 
direction are correlated (as for a TCP connection). 



42 Effect of Maximum Segment Size over 
the TCP throughput 

In this soctk)n wc study in depth the role that the Maximum 
Segment Size (MSS) of a TCP connection has in determining 
the TCP throughput. In the following we assume that the 
TCP packet has a constant size equal to the MSS. 

Figure 7 shows the throu^iput achieved from a TCP 
connection established from a master to a single slave 
versus the MSS. Obviously, when the packet size increase, 
the oveihead due to the IP header and the L2CAP header has 
a decreasing weight. For example, with a MSS equal to 315, 
654, 993 or 1332 bytes the delivery of a single TCP packet 
requires (including all upper layer overheads) exactly an 
integer luimber of DH; packets (I, 2, 3 or 4, respectively). 
Therefore the throughput increase is due to ihe decrease in 
the percentage of the overheads due to the upper layer. 
However, the dominant factor in determining the total 
throughput is the segmentation accomplished by the MAC 
layer. Specifically, as stated in Section 2, the segmentation 
mechanism has to use packets with discrete and fixed 
lengths. 
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Figure 7. TCP throughput vs. MSS 

For example, with a MSS=993 bytes, the delivery of a single 
TCP packet requires (including all upper layer overheads) 
exactly three DHs packets. If we increase the MSS to 994 
bytes, then we need a further DHj packet, which conveys 
only a single byte of information. Therefore we measure a 
sharp decrease in the throughput, as reported in Figure 7. By 
exploiting similar considerations, we can easily understand 
the behavior of the TCP throughput curve shown in Figure 7. 

These results presented so tar, it follows that the 
selection of the MSS value for a TCP connection is a critical 
task in the Bluetooth technology. In the next experiment, 
we investigate the behavior of EDC and RR when the TCP 
connections adopt different MSSs. Specifically, we have 
considered a piconet with a master that establishes seven 
TCP connections towards as many slaves. Figure 8 shows the 
throughput obtained by each connection. The MSS adopted 
by each slave is reported over the related column. We have 
perfoimed this experiment with both EDC and RR scheduler. 
We observe that £DC does not fairly assign the bandwidth to 
the flows. In particular the connection with the smallest MSS 
takes the highest throughput. This is due to the different 
ACK. generation rate that characterizes the TCP connections. 

Due to the delayed ACK mechanism, an ACK is 
generated at least after the reception of two TCP packets 
(after the reception of a single TCP packet if the time interval 
between two consecutive receptions is greater than 200 
msec) [5]. The slave 1 generates a number of ACK. greater than 
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the other coanections, since each ACX packet sect by the 
master towards the slave 1 delivers a new TCP packet. 
Therefore slave ]*$ queue has more tra£Qc to send tban the 
other slaves' queues, and the EDC polls more frequently 
slave! that the other slaves duhng a Cycleup, With RR all the 
slave receive the same polling frequency, therefore the 
throughput difference between the connections are at most 
related to the difTerent percentage of the AO. packets 
occupied by the upper layer overheads (see Figure 7). It is 
worth pointing out that the aggregate throughput achieved 
with EDC is greater than the one achieved with RR, in 
particular 624 Kbytes against 611 Kbytes, even if all the 
TCP source are asymptotic. 




Figure 8* TCP throughput of connections with different 
MSSs 

Figure 8 seems to suggest that RR behaves better than EDC 
for some MSSs. like MSS=1332. More precisely, &om Figure 
8 we can only derive that if a TCP connection adopts a short 
MSS can becotne more aggressive towards TCP connections 
with a long MSS, from a throughput standpoint 
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Figure 9. TCP throoghpat of connections with MSS=1332 

Figure 9 shows the throughput obtained by each connection 
when all of them adopt a MSS=1332. We observe that EDC is 
fair as RR when all the TCP connection have the same MSS. 
Furthermore EDC guarantees a greater throughput than RR 
even if all coimectioDS are asymptotic, It is worth noting 
that the perfomiance gain guaranteed by EDC increase with 
not-asymptotic TCP flows. Specifically, the EDC behavior is 
the same of RR behavior when all the queues arc never 
empty. In the previous section, we have shown that EDC i s 



able to adapt its polling frequency to the traffic 
characteristics when a source alternates periods of activity 
with period of inactivity. Hence, the analysis with 
asymptotic TCP flows is a worst-case analysis. The same 
results are obtained with the other MSSs. 

In conclusion, we can assess that TCP connections with 
a smalt MSS are more aggressive than the ones with a large 
MSS when the EDC algorithm is adopted. Further studies are 
required to introduce a &ir behavior of the scheduler also 
towards TCP connections with different MSSs. 

43 Effect of the ARQ scheme adopted in 

Bluetooth over TCP behavior 

In this section we evaluate the impact of channel errors on 
the TCP behavior. In particular, we are interested in 
investigating the effectiveness of the unnumbered ARQ 
scheme^ adopted by the Bluetooth MAC layer to hide the 
channel errors to the transport layer. 

We model the wireless channel as a discrete two-state 
Markov Chain [11]. In each state the bit error rate (BER) is 
constant, but in one state, i.e. the Bad state , the BER is 
significantly higher than in the other one, i.e. the Good 
state. Hereafter, we will consider the BER in Good state equal 
to 2xlOE-6, and the BER m Bad state equal to lOE-4. We 
assume that, in the Matkov chain model, the average sojourn 
time m each state is expressed as a multiple T of the time 
slot. Furthermore, we assume diat the BER remains constant 
during the packet transmission. We have also considered a 
dififercQt model for the wireless channel with uniformly 
distributed errors. In this case the BER has been chosen 
equal to the average bit error rate experimented in the two- 
state model. This model is used to investigate the impact of 
error recovery mechanism over the TCP both with biirst of 
errors and uniformly distributed errors. 
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U is worth pointing out that the mam objective of this 
section is to illustrate the behavior of the ARQ scheme in 
presence of Inirsty losses on the wireless channel, hence an 
approximate characterization of the wireless channel is 
sufficient. To the best of our knowledge, an exhaustive 
characterization of the piconet wireless environment based 
on experimental measures is not yet available, and the 
numerical values chosen in this paper are compliant with the 
one adopted by other researchers [9], [12]. 

We have studied the impact of the maximum number of 
consecutive retransmissions for the same fragment, say it 



^ A Stop and Wait like error-recovery mechanism [1] 
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ritrjhresh, on tbc TCP pacJc€l-loss probabUity. It is worth 
pointing out thm ^en a fragment is discarded because the 
ritrjhresh is exceeded, the MAC layer discards all the 
subsequent fiugments belonging to the same TCP packet, it 
is possible because the MAC layer itself executes the 
segmentation procedure. 

Figure 10 shows the TCP packet loss probability for a 
connection that adopts a MSS«1332 bytes versus the 
ritrjhresh. We observe that the unnumbered ARQ scheme 
utilized by the MAC layer is very efficient, and for a 
ritrjhresh equal to 4 the lost TCP packets arc less then one 
evoy 10000 packets sent FurthenDOie, we observe that a 
bursty channel is more critical than a unlfonn channel, 
because the concentrated errors cause to close the 
congestion window for the TCP more rapidly than spare 
errors. Finally, in the two bursty cases considered there ore 
not significant differences. 
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Figure 11. TCP packet loss probabUlty with MSS=315 
bytes 

Figure 1 1 shows the same experiments wb^ the connection 
adopts a MSS«315. In Figure 11. the TCP packet-loss 
probability shows the same behavior as in figure lO. Hcnce, 
similar considerations can be taken. 

We can conclude that the ARQ scheme adopted by 
Bluetooth is effective to hide the channel errors to the 
transport layer, just with a ritrjhresh of 4. 

5. Conclusions and Future Work 

The paper proposes a new scheduling algorithm, named EDQ 
for the Bluetooth MAC layer. EDC is evaluated when the 
Bluetooth technology is used as the wireless technology for 
the Intcmci access. EDC exploits master knowledge of local 
queues' occupancy to avoid NULL packet transmission, and 
it employs two polling cycles with different polling rules to 
guarantee a separate and (air treatment of uplink and 
downlink connections. EDC significantly improves the 
throughput of TCP connections when compared to a RR 
scheduler. 

In this paper we have investigated the importance of the 
MSS parameter in determining the TCP throughput. In 
particular, we have shown that the presence of TCP 
connections that adopt different MSSs causes unfairness. 
Further studies arc necessary to in^rove the fairness of 
Bluetooth technology with regard to TCP cotmecdons with 
different characteristics. In all the experiments executed in 
this work we have only considered sources placed in either 
the master or a slave. However the tra£Bc sources can be 
located in any pomt in the Internet The impact of the delays 
introduced when the TCP fiows cross the real Internet 
network will be studied in future works. 
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ABSTRACT 

In this paper wc explore the ability to support multimedia traffic 
in indoor, wireless ad hoc PANs (Personal Area Networks) using 
the Bluetooth technology. We first define the representative ad 
hoc networking applications such as wireless access to the 
Internet, document distribution, videoconferencing, webcasting, 
interaction with sensors and actuators, etc. For such applications, 
we define the perfonnance requirements placed on the PAN. 
There are two technologies now competing for the PAN market: 
the rEEE802.11 "legacy" technology, and the newly introduced 
Bluetooth technology. By IEEE802.1 1, we refier to the operation 
of 802.11 in the DCF mode, which is the mode nnplemented in 
the commercial WaveLAN cards. In the rest of the paper, we will 
use WaveLAN to refer to 802.11 in its DCF mode. We will 
attempt to answer the questions: how effective is the Bhictooth 
technology in supporting collaborative, "virtual ad hoc 
networking" applications and how does it compare with 
WaveLAN? To answer diese questions, we have developed an 
NS-2 model of Bluetooth. We have also developed models of 
ad^tive applications such as voice and video. For WaveLAN, we 
have used the existing NS-2 models. The results show that 
Bluetooth provides better support for real-time applications as 
compared to WaveLAN, It does not exhibit the "capture" behavior 
observed, for example, in WaveLAN. Also, with the addition of 
nodes to the "indoor" space, it adds to the total '^system" capacity 
and gives a better overall throughput 

Categories and Subject Descriptors 

QoS support in wireless access networks 

General Terms 

Measurement, Performance, Experimentation 

Keywords 

Bluetooth, Multimedia, Piconets, Video, Voice, WaveLAN. 
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1 INTRODUCTION - Ad hoc networking 
and Personal Area Networks (PANs) 

With the increasing dependence on the Internet in many aspects of 
their daily lives, users demand ubiquitous, high performance 
Internet access whether they are at work, at home, or on the move. 
Moreover, users on the move are often interested in forming "ad 
hoc" networks to collaborate with colleagues at conferences, or 
more generally to interconnect all their personal devices. This 
type of network, which is centered on the individual himself, is 
often called the Personal Area Network (PAN), 

The PAN is defined as the collection of devices carried by a 
mobile, networked individual (e.g., a professional on the move, an 
Internet-wise tourist, a student attending 'Virtual classes", an avid 
Internet game player, etc). The devices include any subset of; cell 
phone, laptop, earphones, GPS navigator, palm pilot, beeper, 
portable scanner, etc. These devices form his/her PAN (also 
known as personal "bubble"). The connectivity within the bubble 
is wireless (using for example a low cost, low transmit power 
wireless LAN such as Bluetooth). The bubble can expand and 
contract dynamically depending on needs. The bubble may 
connect to wall repeaters for access to the Internet It may also 
be dynamically stretched to include access to sensors aod 
actuators. Such access is critical when the "nomad" walks into a 
new environment and wants to quickly become aware of what is 
going on, or wants to control temperature, adjust the lighting, 
select a particular background music etc. In some cases, the 
nomad himself carries sensors as part of his PAN: for example, a 
patient may walk around in the hospital or nursing home with 
several monitors which transmit to repeaters on die walls, 
allowing customized 24 hour monitoring. 

The PAN communication infrastructure should enable efficient 
support of the above ad hoc networking scenarios. In essence, we 
need a self-configuring communications infrastructure that can: 
(a) provide efficient multimedia access from the PAN to the 
Internet, (b) permit communications with various classes of 
sensor/actuators, and (c) enable voice/data intra and inter-PAN 
networking. The key challenges in the design of the PAN protocol 
architecture are: (a) the design of middleware and adaptive 
application protocols diat provide smooth transition between 
different bandwiddi, connectivity and mobility configurations, 
and; (b) the implemajtation of PAN MAC and networic layer 
protocols and their interconnection with existing public (wired 
and wireless) network infrastructures. 

In the single PAN environment, where nodes are all within 
transmission range of each other, key issues are (I) MAC protocol 
selection, to provide efficient tran^ort of TCP/IP traffic and at 
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the same ume satisfy multimedia traffic requirements; (2) efficient 
handofT; (3) mobile/cellular IP support; and (4) end to end 
adaptivity^ possibly via proxy agents. When commutticating with 
sensors, the PAN MAC and network layer protocols must operate 
in a connectionless, low latency and low overhead mode. In this 
paper, we focus on the "single PAN environmenf operation of 
the PAN*s, where communication occurs only wiihin a PAN, and 
evaluate the support of multimedia in such an environment 

2 THE SCOPE OF TfflS STUDY 

In this smdy, we will assume that each PAN corresponds to a 
single user and consists of a portable device (e.g., laptop, PDA, 
etc.). We will limit ourselves to an application of the PAN N^iiere 
all communication occurs within the PAN. 

In this simplified, single hop setting the performance of the 
network will be for the most part detOTnined by the MAC layen 
Currently, Aere are two leading candidates for such a role: (a) the 
IEEE 802.1 1 MAC protocol and (b) the Bluetooth MAC protocol 
[I]. The IEEE 802.11 protocol is a rather sophisticated protocol 
that includes a fairly broad range of options. In particular, it 
includes the PCF (Point Coordination Function) mode which 
permits a ^'base station^' to poll various terminal in a cellular-type 
environment. It also includes the DCF (Distributed Coordination 
Function) mode, which supports peer-to-peer, ad hoc type 
communications. The DCF version is a random access protocol 
similar to CSMA, with the addition of RTS and CTS (for collision 
avoidance) and of an ACK returned by the receiver after 
successful transmission. In our study we will assume the use of 
the DCF mode, which is the mode implemented in the WaveLAN 
cards. 

A couple of years ago a new MAC protocol was proposed as part 
of the Bluetooth PAN architecture. The Bluetooth MAC protocol 
is a major departure from the IEEE802.il protocol. To start with, 
it uses Frequency Hopping instead of Direct Sequence Spread 
Spectrum, thus exhibiting better protection from co-channel 
interference. Secondly, it uses time/slot synchronization. 
Moreover, it uses a polling type scheme to allow a *^astCT" to 
poll the **slaves" in a given cluster. Bluetooth is expected to 
become very popular due to its low cost (in the order of a few 
dollars per interface). The details of the Bluetooth protocol are 
provided in the next section. Here, it suffices to say that the 
enormous commercial interest in these two PAN candidates and at 
the same time their markedly different characteristics warrants an 
in depth comparison of their performance in various realistic 
indoor scenarios. 

In our simulation experiments we have recreated scenarios that are 
typical of indoor ad hoc networking. We will consider a mixed 
traffic enviroranent, bodi with data (TCP) and with voice/video 
streaming (with fixed and adaptive rate). 

We will be interested in the throughput and delay measures, and 
in the fairness behavior exhibited by the two schemes. The 
simulation results will be reported in Sec 4. In the next section we 
first introduce the Bluetooth architecture and protocols. 

3 BLUETOOTH OVERVIEW 

The Bluetooth system operates in the worldwide unlicensed 2.4 
GHz Industrial-Scientiiic-Medical (ISM) frequency band. To 
make the link robust to interference, it employs a Frequency 
Hopping (FH) technique, in which the carrier firequency is 



changed at eveiy packet transmission. To minimize complexity 
and to reduce the cost of the transceiver, a simple binary Gaussian 
frequency shift keying modulation is adopted. In order to allow 
efficient wideband data transmission the bit rate is 1 Mbit/s. 

Two or more Bluetooth units sharing the same channel fbnn a 
piconet, see Fig. 1(a). 




Figure 1: (a) Bluetooth Piconet (b) Bluetooth Scatternet 

Within a piconet a Bluetooth unit can be either master or slave. 
Within each piconet there may be only one master (and there must 
always be one) and up to seven active slaves. Any Bluetooth unit 
can become a master in a piconet Furthermore, two or more 
piconets can be interconnected, forming what is called a 
scatiemet, see Fig. 1(b). The connection point between two 
piconets consists of a Bluetooth unit that is a member of bodi 
piconets. A Bhjctooth unit can simultaneously be a slave member 
of multiple piconets, but a master in only one, and can only 
transmit and receive data in one piconet at a time, so participation 
in multiple piconets has to be on a time division multiplex basis. 

The Bluetooth system provides full-duplex transmission using a 
slotted time division duplex (TDD) scheme where each slot is 
0.625 ms long, Master-to-slave transmissions always start in an 
even-numbered time slot, while slave-to-master transmissions 
always start in an odd-numbered time slot An even-numbered 
time slot and its subsequent odd-numbered time slot together are 
called a frame. There is no direct transmission between slaves in a 
Bluetooth piconet; transmission is only between a master and a 
slave, and vice versa. 

The commimication within a piconet is organized such that the 
master polls each slave. A slave is only allowed to transmit after 
the master has polled it. The slave will then start its transmission 
in the slave-to-master time slot immediately following the packet 
received from the master. 

Each Bluetooth unit has a globally unique 48-bit IEEE 802 
address. This address is permanently assigned when the unit is 
manufactured. In addition to this, the master of a piconet assigns a 
local active member address (AM ADDR) to each active member 
of the piconet. The AM ADDR is three bits long, is dynamically 
assigned and reassigned, and is unique only within a single 
piconet The master uses the AM ADDR when polling a slave in a 
piconet 

Bluetooth packets can carry either synchronous data on 
synchronous connection oriented (SCO) links mainly intended for 



51 



voice traffic, or asynchronous data on asynchronous connection- 
less (ACL) links. To ensure reliable transfer of data, a fast 
acknowledgment and retransmission scheme is used, only for 
ACL links. In addition, a forward error correction (FEC) scheme 
may be used to further improve reliable packet transmission. 

4 CASE STUDIES AND SIMULATION 
RESULTS 

In this Section, we present simulation results based on a set of 
representative traffic scenarios. One of the main goals was to 
evaluate achievable Bluetooth throughput taking into account 
Interference between difference coexisting piconcts. 

4.1 Simulation Environment 

The simulation environment used in our experiments is NS-2 [2]. 
NS-2 already includes several wireless network models. In 
particular, it supports the IEEE 802.1 1 WaveLAN standard. We 
have augmented NS-2 with the Bluetooth model. The Bluetooth 
model has support for defining multiple piconets that may overlap 
with each other causing interference. The model contains most of 
the standard features of Bluetooth like Frequency Hopping. Multi- 
Slot Packets, Fast ARQ (Automatic Retransmission Query). 

An important feature of the simulator is the Channel Model. 
Frequency hopping is modeled as a pure pseudo-random 
sequence. If two or more transmissions occur on the same 
frequency, the SIR (Signal-to-Intcrference Ratio) is evaluated 
using the gain factor g of each radio channel. The factor g is 
considered constant during the packet transmission and its value 
is obtained by considering the following fectors: 

• path loss due to distance: d*'', where d is the distance 
and ri ranges between 2 and 4. 

• shadowing: log-normal random variable s=10**'' \ where 
8 is a Gaussian variable with a standard deviation* 

• fading: exponential random variable (Rayleigh fading) 
with mean = 1, 

At the receiver i, the SIR is evaluated as: 



where gy is die gain factor between transmitter j and receiver i, 
is the transmitted power and Pn is the noise power in the signal 
bandwidth. 

The receiver model is based on the SIR value. For each portion of 
the packet of length L in which the SIR is considered constant the 
information bit error probability is evaluated by taking into 
consideration the modulation adopted and the FEC coding (if 
adopted). The probability that the portion of the packet is correct 
is calculated assuming independent errors in the segment 

The Bluetooth slave polling strategy that we have used is the one 
given in [3]. It tries to assign slots to slaves based on their traffic 
history and activity. The topology is totally static, which means 
that nodes are not mobile and piconets are set up at the beginning 
of the simulation and do not dynamically change. Again, it is 
important to note that connections are only I or 2-hops, as in 
intra-piconet communication. No inter-piconet communication 
takes place. 



4.2 Conference Hall Case Study 

Our aim is to compare the performance of Bluetooth and 
WaveLAN m a totally ad-hoc environment, where no 
infrastructure in the form of access points is available. This would 
typically model the scenario of a large conference, where a 
number of Bluetooth or WaveLAN devices may be talking to each 
other. The traffic in such a scenario is heterogeneous and 
multimedia in nature, i.e., TCP, voice and video. It is assumed 
here that any two devices wanting to communicate are close 
enough to be in the same piconet and thus communicate through 
the master. This will be a realistic model for ad-hoc group 
collaboration where members of the same team will be sitting 
nearby and will interact with each other by exchanging files and 
engaging in videoconference. 

In the experiment, we consider a 50m ♦ 1 00m room, in which 
nodes are distributed according to a uniform random distribution. 
In the case of Bluetooth, piconets are formed by clustering the 
nodes close enough to each other. The number of slaves present in 
each piconet is chosen randomly. Also, some piconets overlap 
with each other incurring a certain fraction of collisions. The 
traffic consists of a mix of TCP, Voice and Video. The number of 
TCP, voice and video connections are in the ratio 1:1:1. Unless 
otherwise stated, the coimections start at 0.5s and run till the end 
of the simulation. The TCP data connections are always active 
large file backlogs, with 500-byte packets. The voice connections 
are modeled according to the Brady model [4]. In particular, the 
voice connections are "on-ofT sources. The on and off times are 
exponentially distributed, with mean I s and 1.35 s respectively. 
The voice-coding rate is 8 kbit/s and the packetisation period is 20 
ms, which gives a payload sire of 20 bytes. Header compression is 
assumed for voice packets in Bluetooth and the total packet size is 
30 bytes. Voice packets are sent using RTP over UDP. Each 
experiment lasts 32 seconds of simulation time. In order to probe 
the sensitivity of performance to population size and to the 
number of simultaneous connections, we perform different 
experiments choosing differait values of number of nodes and 
connections. 

43 Video Traffic 

The video sources are represented by real traces. We use the Star 
Wars trailer clip encoded using Intel's H.263 compatible codec. 
The traces have been smoothed using a simple technique, namely 
a frante as returned by the codec is distributed uniformly in time 
within the frame interval using a target of 200 byte packets. There 
is no other smaller time scale transport mechanism and the 
generated packets are simply sent through the network with UDP. 
A few seconds from the resulting sources for the codec is shown 
in Fig 2. A description of the framework used in the experiments 
can be found in [5]. The platform used in the experiments is based 
on ns, augmented to support video agents and end-to-end adaptive 
video agents [7]. 

We investigate adaptive as well as non-adaptive video streaming. 
The former uses average rates of 48, 64, 80, 1 28 and 256Kbps for 
the two codecs, while the non-adaptive cases use the 256Kbps 
trace. The adaptation mechanism is based on an end-to-end, 
periodic (I sec) feedback that contains the number of packets 
received during the feedback interval. This feedback is used by 
the server to compute the RTP loss rates. The server then changes 
its rate using a min/max loss threshold. 
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Figure 2: A few seconds from the H263 source trace (sec, bytes) 

Below the minimum packet loss rate (5%) the server attempts to 
additively increase its rate. When the loss rate is above the 
maximum loss threshold (15%) the server reduces the sending 
rate, choosing a rate among the 5 available rates that is 
appropriate to support the rqx>rted loss rate. For example, if the 
current rate is 128 Kbps and the loss rate is 50% the sending rate 
drops to 64Kbps. 

The following graphs (Fig 3(a) and (b)) illustrate this behavior in 
a random 30-node 60-connectton experiment This initial 
experiment targets at showing the adaptive behavior whh the two 
h4AC protocols. The scenario is generated as mmtioned in 
Section 4.2, but now 90% of the voice, video and TCP 
connections are created at 8.6s and finish at the 16.6s. The goal is 
to study die adaptive behavior of a video connection that lives 
throu^out the experiment (i.e. from Os to 328). As the feedback 
indicates, the server downgrades the sending rate or attempts a 
higher rate. We show the loss rates as calculated when a feedback 
packet is received, the per-packet delays and the server selected 
average rates for the two cases. First, we note that when the 
additional connections enter the network (from 8.6s to t6.6s) in 
WaveLAN, the video connection downgrades to the lower 
possible transmission rate because the loss feedback goes beyond 
the threshold. On the other hand, in Bluetooth the loss rates are 
lower, the transmission rates remain higher and the downgrading 
is in all cases gradual (one layer at a time). These indicate that the 
network response is more regular allowing for efficient feedback 
control widi fewer oscillations. This is true not only for the 
connection shown but for die other competing adaptive 
connections as well. It is interesting to note that in the congested 
network, fewer packets get lost in the Bluetooth case, but their 
delay is significantly increased This can be explained by the 
difference in the Bluetooth and WaveLAN MAC layers. 
WaveLAN retransmits a collided packet a finite number of times 
and then drops the packet if transmission is unsuccessful. Since 
collisions are very high for large number of connections in 
WaveLAN, a larger number of packets get dropped. In Bluetooth, 
on the other hand, the chances of a collision are veiy low because 
of the controlled access to the channel and the frequency hopping 
behavior. Thus, a larger number of packets reach die destination, 
but these fill up the link layer queues and make delays larger. 
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Figure 3(a): Bluetooth End-to-End Adaptation 
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Figure 3(b): WaveLAN £nd-to-End Adaptation 



4.4 Aggregate results -^on-Adaptive Video, 
TCP and Voice 

We first performed the experiments described in Section 4.2 with 
TCP, Voice and Non- Adaptive Video connections. 

4.4.1 Video and TCP 

The aggregate throughput is the same for all experiments for 
WaveLAN. Bluetooth, however, manages to grow the aggregate 
throughput as the number of nodes increases. The smaller range 
and formation of additional piconets adds capacity to the network. 

A generic difference in the way the two source types, TCP and 
Video, share the network bandwidth is illustrated in Fig 4. In 
WaveLAN, individual TCP connections are allowed to grow their 
window and 'capture' the channel. When this happens, video 
connections suffer increased loss rates. On ttie other hand, the 
presence of polling in Bluetooth allows the video connections to 
share the channel with the TCP. In fact, with Bluetooth, the video 
achieves its frill rate for different configurations. Several 
measurements are reported in Fig. 4 as shown by the caption 
below each sample (Number of nodes; number of connections; 
WL vs. BT). It can also be noted from Fig, 4 that the total 
throughput for WaveLAN is higher dian that of Bluetooth for the 
30 nodes, 30 connections case. As the number of connections 
increases, the total throughput for Bluetooth increases with 
respect to WaveLAN since larger connections means more 
collisions in WaveLAN. Also, a larger number of nodes causes 
the total throughput for Bluetoodi to be higher since it leads to 



53 



formation of more piconets and hence, addition to system 
capacity. 
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Figure 4: H.263 Non adaptive video and TCP connections 
aggregate tlirougliput. 

From Fig. 5, we see that the loss rates for video are much higher 
in the WavcLAN case where the contention between the 
connections, especially TCP and video, allows some TCP 
connections to increase their window and capture the channel, 
locking out pactcets from the 256Kbps video connections. On the 
other hand Bluetooth shows less than 5% packet loss in all cases. 
Due to less packet retransmissions die Bluetooth case will save a 
significant amount of power that is particularly important in 
battery-powered devices. 
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Figure 5: Loss Rates for video connections for H.263. 



4.4,2 Voice 

The significant parameter that needs to be studied for voice is the 
delay. The complementary cumulative delay distributions for 
voice in Bluetoodi and Wavel-AN for 30 nodes and 60 
connections with non-adaptive MPEG Video are shown in Figs. 
6(a) and (b). 

It is seen that the delays suffered are much lower in Bluetooth 
than in WaveLAN. From the complementary cumulative 
distribution graph, we note that a packet loss ratio of less than 5% 
can be obtained for a play-out buffer of about 80 ms in the case of 
Bluetooth, whereas a play-out buffer of more than 350 ms is 
required to achieve the same efTect with Wavcl-AN. Typically, a 
delay in excess of 300nis is considered unsuitable for interactive 
voice communications. 



Voice in WUn 




^ ^ ^ ^ ^ ^ ^ ^^"^^^^^^ \ 



Figure 6 (a): Voice Delay Distribution for WaveLAN 
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Figure 6 (b): Voice Delay Distribution for Bluetooth 

To explain the very high Wavel-AN delays, recall that the 
scenario considered here is of a very congested network with large 
number of connections. In such a network, the uncontrolled 
access to the channel and the large number of collisions and 
retransmissions in case of WaveLAN leads to large delays. 
Bluetooth, on the other hand, has a very controlled access to the 
channel determined by the polling scheme. This keeps the delays 
low and well bounded. 

4.5 Aggregate results with Adaptive Video 

In this section we repeat the experiments of Section 4.2 with 
adaptive in place of non-adaptive video. The video sources adapt 
through the use of a periodic end-to-end feedback containing the 
RTP loss rates, as described in Section 4.3. 



Figure 7: H.263 a^egate server sent rates 
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First, we show the aggregate source sending rates in Fig 7. This 
quantity is influenced by the loss rates reported to the server and 
represents the application requested bandwidth. The sum of the 
feedback packets received in the WaveLAN configurations was 
1215 whereas in Bluetooth 1216 feedback packets were received. 
WaveLAN tends to transmit less, especially at high connection 
density and load, showing that a smaller number of packets were 
received at the destination. 

Next we look at the loss rates with adaptive video in Fig 8. The 
controlled, Bdq}tive polling environment of Bluetooth, with less 
reverse channel problems managed to eliminate the video loss 
rates aknost completely in the adaptive case in our experiments. 

The highest aggregate loss rate in Bluetoodi is 1.32%. In 
WaveLAN too the loss rates are reduced to half with respect to the 
non-adaptive case shown in Fig 5. 
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Figure 8: Loss Rates for Adaptive IL2(B Video 

Next we examine adaptive video throughput in Fig 9. 1Mbps 
Bluetooth throughputs are again comparable to the lOWfbps 
WaveLAN total throughput As video connections adapt they 
allow TCP connections to get more bandwidth. In Bluetooth 
video adaptation reduces loss rate to less than 1% in most cases 
whereas in WaveLAN adaptive video connections suffer 25% to 
30% loss rates. 

The total throughput is higher in WaveLAN than in Bluetooth for 
lower number of nodes. As more piconets are formed, Bluetooth 
adds bandwidth and surpasses the constant WaveLAN bandwidth, 
which is independent of the number of nodes. 




Figure 9: H.263 adaptive video and TCP connectioiis 
aggregate throughput 



5. CONCLUSIONS 

In this paper we have evaluated the efficacy of the Bluetooth 
technology in supporting ad hoc indoor communications. The 
simulation results show diat Bluetooth performs very well in 
mixed data and real time traffic scenarios typical of such 
environments. In particular, it guarantees service quality to 
multimedia streams while providing fair share of capacity to TCP 
users. It does not suffer from the TCP capture behaviour exhibited 
by WaveLAN. Though the total system througjiput is larger for 
WaveLAN for small number of nodes, Bluetooth can exceed the 
WaveLAN diroughput when number of nodes becomes large, by 
using multiple, overlaid piconets. Adaptive video applications fare 
better with Bluetooth than WaveLAN, in part because die polling 
schedule of Bluetooth seems to offer a more stable service to 
adaptive video, precluding oscillations. It is to be noted again that 
these experiments were performed with die DCF mode of 802, 1 1 . 
In the future, we plan to repeat some of the experiments using the 
PCF mode. 

Work is currently in progress in several directions. A Scattemet 
model is being developed, to allow the interconnection of 
piconets. Sensor interaction experiments are planned, with various 
mobility models. 
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